'Oracle' 카테고리의 글 목록 (17 Page)

'Oracle'에 해당되는 글 219건

2009.11.28 trigger(primary key & foreign key 관련)
2009.11.27 Administering User Security
2009.11.26 Enqueue vs Latch
2009.11.26 2009년 11월 26일 수업내용
2009.11.25 2009년 11월 25일 수업내용
2009.11.24 2009년 11월 24일 수업내용
2009.11.24 Static Data Dictionary View vs Dynamic Performance View 2
2009.11.24 수동 DB 생성 / 네트워크 설정 (10gr2, linux)
2009.11.23 2009년 11월 23일 수업내용
2009.11.22 Explain Plan과 Execution Plan의 차이

trigger(primary key & foreign key 관련)

부모와 자식의 관계인 t1과 t2테이블이 있다.
t1테이블에 데이터가 update되면 관련된 t2테이블의 데이터도 같이 변경되는
간단한 트리거를 만들어보자.

처음에는 테이블 생성시 on delete cascade 옵션과 같이
on update cascade가 있는 줄 알았는데 그런건 없고, 따로 트리거를 만들어야 한다.

아래와 같이 t1과 t2 테이블 2개를 생성한다. t1과 t2는 부모와 자식관계이다.

create table t1
(col1 number,
primary key(col1));

create table t2
(col1 number,
col2 varchar2(10),
foreign key(col1) references t1(col1));

t1과 t2에 데이터를 넣는다.

insert into t1 values(1);
insert into t1 values(2);
insert into t1 values(3);

insert into t2 values(1, 'a');
insert into t2 values(2, 'b');
insert into t2 values(3, 'c');

트리거를 생성한다.
(물론 유저는 create trigger 권한이 있어야한다.)

create or replace trigger tri1
after update on t1
for each row
begin
update t2
set col1=:new.col1
where col1=:old.col1;
end;
/

t1테이블에 데이터를 입력해본다.

update t1
set col1=9
where col1=1;

데이터가 잘 변경되었음을 확인한다.

select * from t1;
select * from t2;

cf. 테이블 생성시 on delete cascade 옵션에 따른 간단한 테스트

create table t1
(col1 number,
primary key(col1));

create table t2
(col1 number,
col2 varchar2(10),
foreign key(col1) references t1(col1) on delete cascade);

insert into t1 values(1);
insert into t1 values(2);
insert into t1 values(3);

insert into t2 values(1, 'a');
insert into t2 values(2, 'b');
insert into t2 values(3, 'c');

delete from t1 where col1=1;

select * from t1;
select * from t2;

'Oracle > PL_SQL' 카테고리의 다른 글

instead of trigger (0)	2009.11.18
print_table프로시져 만들기 (0)	2009.11.18
trigger (0)	2009.11.17
package의 overloading (0)	2009.11.17
테이블 변경시 관련 procedure, function, package 확인 (0)	2009.11.16

Posted by 자수성가한 부자

Administering User Security

유저 관리
- 생성, 삭제
- 권한 관리
- Role 관리
- profile

유저 생성 전에 알아보아야 할 사항들
(isql*plus에서 질의할 것)

SQL> select * from dba_users;
SQL> select * from dba_tablespaces;
SQL> select * from dba_profiles;
SQL> select * from dba_roles;
SQL> select * from dba_sys_privs;
SQL> select distinct privilege from dba_sys_privs order by 1;

유저 생성 예)

SQL> create user phil
         identified by cat
        default tablespace users
        temporary tablespace temp_a
        quota 10m on users
        quota 10m on users5
        account lock
        profile default
        password expire;

권한을 준다.

SQL> grant create session, create table to phil;

※ consumer group은 plsql로 한다.

SYS 유저와 SYSTEM 유저

sys(root) : data dictionary, internal table 소유
system(dba) : 추가적인 table 생성, session
※ 운영상 유의점 : SYS유저로는 작업을 하지 않는 것이 좋다.

Autnentication
- 이 유저가 등록되어 있는 유저인가?
- 인증의 종류
    - DB 인증
    - OS 인증
    - 패스워드 파일 인증

sysdba 인증
- DB인증 (인증 안됨)
    : shutdown(idle instance) 상태에서 인증이 되어야 하기 때문에
      sqlplus oracle/oracle, sqlplus jgh/jgh
      -> ORA-01034: ORACLE not available 에러 발생

- OS 인증
    : sqlplus / as sysdba로 접속 가능
      {유저가 등록되어 있고, 그룹이 oinstall, dba인 유저(OS의 /etc/passwd, /etc/group 참조)}
      telnet으로 들어온 유저에 대해서 sysdba의 권한을 주고,
      sqlplus 유저/암호@XXXXXX 로 접속하는 유저에게는 sysdba의 권한을 주지 않음

- 패스워드파일 인증
    : 원격지에서 접속하는 유저들에게 sysdba의 권한을 주기 위해 만든다.
    위치 : ORACLE_HOME/dbs
    이름 : orapwsid
    패스워드 파일생성

OS] orapwd file=$ORACLE_HOME/dbs/orapwjgh_db password=nemam entries=5
파일 이름은 orapw + sid
entries=5 는 5명까지 등록가능하다는 의미.

접속

sqlplus sys/nemam@ip:1521/jgh_db

->ORA-01034: ORACLE not available 에러 발생

sqlplus sys/nemam@ip:1521/jgh_db as sysdba

-> sysdba 유저로 접속 가능

일반 유저의 인증
- db 인증(passwd)

SQL> create user john identified by cat;

일반 유저의 os 인증(!권장되는 방식이 아님)

SQL> show parameter os

os인증(external)

1. oracle이 아닌 일반 OS 유저로 sysdba되기

터미널 1

$ su - root
$ useradd -g oinstall -G dba user1
$ passwd user1

터미널 2

$ su - user1
$ export ORACLE_HOME=/u01/app/oracle/product/10.2.0/db_1
$ export ORACLE_SID=jgh_db
$ export PATH=$ORACLE_HOME/bin:$PATH; export PATH
$ export LD_LIBRARY_PATH=$ORACLE_HOME/lib:/lib:/usr/lib; export LD_LIBRARY_PATH
$ sqlplus / as sysdba

2. password file 인증

터미널 1

$ su - oracle
$ export ORACLE_SID=jgh_db
$ cd $ORACLE_HOME/dbs
$ rm orapwikdb
$ orapwd file=$ORACLE_HOME/dbs/orapwikdb password=nemam entries=5
$ rm spfileikdb.ora
$ vi initikdb.ora

remote_login_passwordfile = exclusive

터미널2

$ sqlplus / as sysdba
$ shutdown abort

window에서 접속

OS] sqlplus sys/nemam@192.168.0.10:1521/ikdb as sysdba
SQL> startup

참고 : http://www.adp-gmbh.ch/ora/admin/password_file.html

프로파일이란?
- 자원사용 및 암호관리에 관한 설정
- 여러개의 Profile을 만들 수 있다.

예)

CREATE PROFILE "DEV_PROF"
CPU_PER_CALL 1000 CONNECT_TIME 60 IDLE_TIME 60 SESSIONS_PER_USER 1000 LIMIT CPU_PER_SESSION 1000
LOGICAL_READS_PER_SESSION 100 LOGICAL_READS_PER_CALL 100 PRIVATE_SGA DEFAULT COMPOSITE_LIMIT DEFAULT PASSWORD_LIFE_TIME 30 PASSWORD_GRACE_TIME 5 PASSWORD_REUSE_MAX unlimited PASSWORD_REUSE_TIME 365 PASSWORD_LOCK_TIME 5/1440 FAILED_LOGIN_ATTEMPTS 3 PASSWORD_VERIFY_FUNCTION verify_function

※ verify_function
- 패스워드 생성에 복잡성을 부여하기 위한 pl/sql
- 위치 : $ORACLE_HOME/rdbms/admin/utlpwdmg.sql

권한 관련?

롤(role)이란?

롤 생성 방법

보안을 강화할 목적으로 default role과 암호를 준다.

예)
a role (default) :select 관련 권한
b_role / lion : insert, update, delete, select 관련 권한.

로그인 하면 첫 권한은 a_role이다.(default)

insert나 update, delete 등을 하고 싶을 때 role을 바꾼다.
바꿀때는 패스워드를 입력한다.

SQL> set role b_role identified by lion;

기타사항

bility Architecture and Best Practices (HAA)
메뉴얼(10r1, 10gr2) 에서 찾아볼 것. (이렇게 하는 것이 좋다라는 일종의 지침)

'Oracle > Admin' 카테고리의 다른 글

Managing Data and Concurrency (주요내용 : Lock) (0)	2009.12.01
Managing Schema Objects-1 (0)	2009.11.30
2009년 11월 26일 수업내용 (0)	2009.11.26
2009년 11월 25일 수업내용 (0)	2009.11.25
2009년 11월 24일 수업내용 (0)	2009.11.24

Posted by 자수성가한 부자

Enqueue vs Latch

[2] Enqueue와 Latch 개념 이해하기

DBMS의 가장 주된 기능 중에 하나는 동일 자원에 대한 동시 액세스를 관리하는 것이며, 이를 위해 오라클이 사용하는 대표적인 제어 구조가 Enqueue와 Latch이다.

Enqueue와 Latch는 모두 특정 자원에 대한 접근을 serialize하는 것이 목적이라는 점에서는 같은 Lock의 일종이지만 관리방식이나 용도에서 차이가 있다. Enqueue는 이름에서 보듯 Queue를 통해 관리된다. 대상 자원에 대한 Owner, Waiter, Converter Queue를 관리하면서 먼저 요청한 순서대로 Lock을 획득하도록 하는 구조이며, Exclusive 모드 뿐 아니라 다양한 수준의 공유를 허용한다. 대표적인 것이 테이블 데이터를 Update할 때 사용되는 TM, TX enqueue이다.

반면에, Latch는 Enqueue에 비해 훨씬 단순한 구조로서 매우 짧은 시간 내에 획득되고 해제된다. Queue를 통해 관리되지 않으므로 먼저 Request한 프로세스가 먼저 latch를 획득한다는 보장이 없으며, 대부분의 경우 Exclusive모드로만 획득된다. Latch는 주로 SGA의 특정 메모리 구조체에 대한 액세스(library cache latch, cache buffers chains latch) 혹은 메모리 할당 시 (shared pool latch) 사용되거나 오라클의 중요한 코드가 동시에 수행되지 않도록 하기 위한 용도로(redo writing latch) 사용된다.

Latch는 Enqueue보다는 하위 level에서 Locking 자체의 부하를 최소화하며 작동하는 제어 메커니즘이라고 할 수 있으며, 실제로 Enqueue 역시 내부적으로는 Latch (enqueues, enqueue hash chains latch)에 의해 운영된다는 점을 생각하면 둘 사이의 차이를 쉽게 이해할 수 있을 것이다.

■ Enqueue

Enqueue 정보는 내부적으로 Enqueue Resource 배열과 Enqueue Lock 배열에 저장된다. 특정 자원에 대한 Lock이 요청되면 대상을 하나의 Resource로 정의하여 할당하고 그 Resource에 대해 관련 Lock 정보를 Owner, Waiter, Converter 가운데 하나로서 Link시키는 방식으로 운영되며, 이러한 정보는 V$RESOURCE와 V$LOCK 뷰를 통해 조회해 볼 수 있다. V$RESOURCE와 V$LOCK은 1:M 관계로 하나의 Resource에 대하여 여러 건의 Lock 레코드가 Owner (LMODE>0, REQUEST=0), Waiter (LMODE=0 ,REQUEST>0), Converter (LMODE>0, REQUEST>0) 중 하나로서 대응된다. → V$LOCK 설명을 확인하세요. System type도 눈여겨 보세요.

Enqueue Wait이 발생하는 것은 다른 세션이 이미 나보다 먼저 해당 자원에 대한 Lock을 잡고 있으므로 인해 내가 원하는 모드로 Lock을 할당 받을 수 없기 때문이다. 자신이 필요로 하는 Lock의 획득에 실패한 세션은 Owner가 작업을 완료하고 자신을 깨워줄 때까지(세마포어를 포스트해줄 때까지) Waiter 혹은 Converter Queue에서 대기하게 되며, 기다려도 소식이 없으면 3초 간격으로 timeout에 의해 일어나 혹시 Deadlock 상황이 아닌지 점검해 본 후 다시 Sleep에 빠져들기를 반복하게 된다.

튜닝관련 자료를 보다 보면 가끔 Enqueue에 대한 Wait이 많은 경우에 Enqueue_resource나 Enqueue_lock 파라미터를 증가시켜 주어야 한다는 가이드를 보게 되는 경우가 있는데 이 파라미터들은 Enqueue resource와 lock 배열의 크기를 늘려줄 뿐 특정 Enqueue 자원에 대한 동시 경합을 해소시키는 것과는 상관이 없다.

Enqueue Wait를 해소하기 위한 구체적인 방법은 Enqueue type에 따라 달라지지만 결국은 Enqueue를 불필요하게 요청하는 경우가 없는지를 살펴 Enqueue에 대한 요청을 최소화하고 Enqueue를 점유하는 시간을 최대한 단축시키는 것이다.

TX Enqueue에 대한 Wait은 대상 자원에 대한 Lock을 소유하고 있는 세션과 그 세션이 수행 중인 SQL을 찾아 트랜잭션이 장시간 지속되고 있는 이유가 무엇인지 애플리케이션 측면에서 조사해야 하며, SQ enqueue는 Sequence 값 할당 시 발생하는 경합이므로 cache값을 늘려줌으로써 완화시킨다거나 ST Enqueue의 경합이 존재할 경우에는 Locally managed tablespace를 사용하거나 Initial, Next 등의 extent 크기를 적당한 값으로 조정하여 실시간 공간할당을 감소시켜주는 등의 방법들이 Enqueue Wait에 대처하는 대표적인 사례이다.

지난 호에서 소개한 Session Waiter 스크립트는 Enqueue Wait 이벤트에 대해서 Enqueue type과 모드를 함께 표시하여 주도록 하고 있으며, 참고로 Enqueue type별 누적 Wait현황을 확인하고자 하면 아래 SQL을 수행하면 된다.

select q.ksqsttyp type,
           q.ksqstsgt gets,
           q.ksqstwat waits,
            round(q.ksqstwat/q.ksqstsgt,3) waitratio
       from sys.x$ksqst q
where q.inst_id = userenv('Instance')
      and q.ksqstsgt > 0
order by waits desc
/

■ Latch

오라클 운영 시에 하위레벨에서 내부적으로 처리되는 다양한 조작들이 latch의 관할 하에 수행되는데 V$LATCHNAME을 조회해보면 (9i 기준으로) 239 종류나 되는 Latch가 존재하는 것을 확인할 수 있다. 이 가운데 우리가 자주 접하게 되는 latch는 다음과 같은 정도이며 각 Latch의 기능은 관련 SGA별 Wait를 다룰 때 간단하게나마 소개하도록 하겠다.

Shared pool	library cache latch, shared pool latch, row cache objects
Buffer Cache	cache buffers chains latch, cache buffers lru latch, cache buffer handle
Redo log	redo allocation latch, redo copy latch, redo writing latch
OPS	dlm resource hash list

▷ Willing to wait 모드와 No-wait 모드

Latch 획득 방식은 No-wait과 Willing to wait 의 두 가지 모드로 구분할 수 있다. Willing to wait 모드는 Latch의 획득에 실패하면 좀더 시간을 끌면서 해당 Latch를 잡을 때까지 재시도를 해보는 방식을 말한다. 일차적으로는 CPU를 놓지 않고 정해진 횟수만큼 Spinning을 한 후 재시도를 해보다가 그래도 실패하면 CPU를 놓고 Sleep하다가 timeout되어 재시도하는 작업을 반복하면서 Latch의 획득을 노력하게 된다.

Latch가 sleep에 들어가게 되면 'latch free' wait event 대기가 시작된다. sleep의 지속시간은 sleep 횟수가 늘어갈수록 점점 길어지게 되는데, 따라서 V$LATCH의 Gets와 Sleeps의 비율과 함께 Sleep1~sleep4 항목에서 몇차 Sleep까지 발생했는지 여부도 각 Latch Wait의 심각성을 판단하는 요소 가운데 하나가 된다.

No-wait 모드는 Willing to wait과는 달리 더 이상 미련을 두지 않고 해당 Latch에 대한 획득을 포기하는 것이다. No-wait 모드가 사용되는 경우는 두 가지가 있는데, 하나는 동일한 기능을 하는 Latch가 여러 개 존재하여 그 중에 하나만 획득하면 충분하여서 특정 Latch에 미련을 가질 필요가 없는 경우이다. 물론, 이 때에도 같은 기능의 모든 Latch에 대한 시도가 실패로 끝날 경우에는 Willing to wait 모드로 요청을 할 것이다. No-wait 모드가 사용되는 다른 한가지 경우는 dead lock을 피하기 위해서 이다.

오라클은 기본적으로 latch dead lock 상황을 피하기 위하여 모든 Latch에 level을 부여하여 (select * from v$latch order by level# desc;) 정해진 순서를 따라서만 Latch를 획득하도록 하고 있는데, 필요에 의해 이 규칙을 어기고 Latch를 획득하고자 할 경우 일단 No-wait 모드로 시도를 해보는 것이다. 다행히 Latch를 잡으면 좋은 것이고 비록 latch를 잡을 수 없더라도 무한정 기다림으로써 dead lock 상태에 빠지는 일은 피할 수 있는 것이다. No-wait 모드의 Latch작업에서는 당연히 Latch 관련 wait이 발생하지 않으며, redo copy latch를 제외하고는 Willing to wait 모드로 Latch를 획득하는 경우가 훨씬 많다.

▷ Parent latch와 Child latch

Latch 가운데에는 동일 기능을 하는 Child latch들의 set으로 운영되는 Latch도 있으며 하나의 Latch로만 운영되는 Latch도 있다. 전자의 대표적인 예로는 cache buffers chains (버퍼캐쉬 블록 들을 같은 이름의 다수의 Latch가 나누어 담당)가 있으며, 후자의 예로는 shared pool latch (shared pool내에서 메모리 할당을 위해 획득해야 하는 Latch로 시스템에 하나만 존재)가 있다.

이와 같은 Latch 관련 통계 정보는 Parent latch와 Child latch의 개념으로 관리가 되는데 Latch set에서 개별 Child latch에 대한 통계정보는 V$LATCH_CHILDREN 뷰를 통해 조회할 수 있으며, 단일 Latch 혹은 Latch set의 마스터 Latch (parent)에 대한 통계정보는 V$LATCH_PARENT 뷰를 통해 조회할 수 있다.

지금까지 한 회 분량을 할애하여 Enqueue와 Latch에 대해 요약해본 이유는, 많은 Waiting이 SGA내의 공유자원 (Block, Cursor 등)에 대한 경합으로 인해 발생하며 이러한 경합은 다시 해당 자원에 대한 동시 액세스를 제어하는 Enqueue와 Latch에 대한 경합으로 흔히 드러나게 되므로 오라클의 Wait Event를 모니터링하기 위해서는 Enqueue와 Latch의 구조와 작동원리에 대해 이해하는 것이 필수적이기 때문이다.

출처 : http://www.oracle.com/technology/global/kr/pub/columns/dbtuning01.html

'Oracle > 용어정리' 카테고리의 다른 글

Oracle LogMiner (0)	2009.12.10
Tuning(튜닝)이란? (0)	2009.12.09
SCN (0)	2009.11.17
index (0)	2009.11.17
dead lock (0)	2009.10.29

Posted by 자수성가한 부자

2009년 11월 26일 수업내용

UMF vs OMF
: file의 관리를 사용자가 하는가 ? 오라클이 하는가에 따라 구분.
OMF는 9i부터 나옴

UMF

- User Managed File의 약자
- 일반적으로 테이블스페이스나 리두파일의 생성, 삭제시 사용자가 수동으로 해줘야함.

OMF

- Oracle Managed File의 약자
- 오라클 데이터베이스에 의해 생성되고, 관리되는 파일.
- 파일 관리의 편이성. 삭제할 때 OS에 직접가서 지우다가 생기는 실수를 유발할 가능성이 배제하기 위해 사용
- OMF에 의해 생긴 파일의 이름은 바꾸면 안됨
A feature of the Oracle database which manages the creation, naming and deletion of Oracle database files within dedicated areas of disk, to minimize the need for DBAs to concern themselves with such specifics.

실습을 해보자.

파라미터를 설정한다.
(db_create_file_dest : 데이터 파일과 템프 파일이 생성되는 위치,
db_create_online_log_dest_n : 리두 로그 파일과 컨트롤 파일이 생성되는 위치,
db_recovery_file_dest : RMAN 백업 위치)

SQL> alter system set db_create_file_dest = '/u01/app/oracle/oradata/jgh_db';
SQL> alter system set db_create_online_log_dest_1 = '/u01/app/oracle/oradata/jgh_db';
SQL> alter system set db_create_online_log_dest_2 = '/u01/app/oracle/oradata/jgh_db';

잘 설정되었는지 확인해본다.

SQL> show parameter db_create

테이블 스페이스를 생성하고, 파일이 잘 생성되었는지 확인해본다.

SQL> create tablespace ts1;
SQL> !ls -R /u01/app/oracle/oradata/jgh_db

테이블 스페이스를 삭제하고, 잘 삭제되었는지 확인해본다.

SQL> drop tablespace ts1;
SQL> !ls -R /u01/app/oracle/oradata/jgh_db

로그 파일을 생성하고 확인해본다.

SQL> alter database add logfile;
SQL> !ls -R /u01/app/oracle/oradata/jgh_db

로그파일을 삭제하고 확인해본다.

SQL> alter database drop logfile group 1;
SQL> !ls -R /u01/app/oracle/oradata/jgh_db

OMF + ASM (Automatic Storage Management)

관련 실습 (그냥 참고 삼아서 볼 것)

CREATE DISKGROUP dg1
NORMAL REDUNDANCY
FAILGROUP controller1 DISK
   '/devices/diska1',
   '/devices/diska2',
   '/devices/diska3',
   '/devices/diska4'
FAILGROUP controller2 DISK
   '/devices/diskb1',
   '/devices/diskb2',
   '/devices/diskb3',
   '/devices/diskb4';

CREATE DISKGROUP dg2
NORMAL REDUNDANCY
FAILGROUP controller1 DISK
   '/devices/diska11',
   '/devices/diska12',
   '/devices/diska13',
   '/devices/diska14'
FAILGROUP controller2 DISK
   '/devices/diskb21',
   '/devices/diskb22',
   '/devices/diskb23',
   '/devices/diskb24';

SQL> alter system set db_create_file_dest              = '+dg1';          -- Database Area
SQL> alter system set db_create_online_log_dest_1 = '+dg1';
SQL> alter system set db_create_online_log_dest_2 = '+dg1';

SQL> alter system set db_recovery_file_dest         = '+dg2';         -- Flash Recovery Area(FRA)

DMT vs LMT
: extent의 관리를 data dictionary에서 하는가? 아니면 로컬에서 하는가? 에 따라 구분된다.

DMT
- Dictionary Managemant Tablespace의 약자
- FET$, UEF$와 관련.
- 시스템 테이블 스페이스가 DMT명 DMT와 LMT를 같이 쓸 수 있음

create tablespace users
datafile '/u01/app/oracle/oradata/jgh_db/users.dbf' size 10m
extent management dictionary;

LMT
- Locally Managed Tablespace의 약자
- 공간을 할당하면 공간에 대한 기본적인 정보를 공간 내에서 관리
- 시스템 테이블 스페이스가 LMT면 LMT만 가능
- 디폴트

create tablespace users
datafile '/u01/app/oracle/oradata/jgh_db/users.dbf' size 10m
extent management local [option];

※[option]에 따라 extent의 크기가 결정된다.
extent management local autoallocate;       -- 오라클 마음대로
extent management local uniform;              -- 모든 extents의 크기 : 1m로 통일
extent management local uniform size ?;    -- 모든 extents의 크기 : ? 로 통일

FLM vs ASSM
: segment의 관리를 segment의 헤더의 freelist를 이용하여 할 것인가?

FLM
-  FreeList Managemant의 약자

ASSM
- Automatic Segment Storage Management의 약자
- Block을 어떻게 관리할 것인가?

-- LMT + ASSM : default

create tablespace users
datafile '/u01/app/oracle/oradata/jgh_db/users.dbf' size 10m
extent management local
segment space management auto;

-- LMT + FLM

create tablespace users
datafile '/u01/app/oracle/oradata/jgh_db/users.dbf' size 10m
extent management local
segment space management manual;

-- DMT + ASSM
: 불가능: ORA-30572 : AUTO segment space management not valid with DICTIONARY extent management

create tablespace users
datafile '/u01/app/oracle/oradata/jgh_db/users.dbf' size 10m
extent management dictionary
segment space management auto;

-- DMT + FLM : 오래된 방식으로 가능하면 사용하지 않는게 좋음

create tablespace users
datafile '/u01/app/oracle/oradata/jgh_db/users.dbf' size 10m
extent management dictionary
segment space management manual;

※ 참고 : DMT의 Storage 옵션 이해

create tablespace users5
datafile '/u01/app/oracle/oradata/jgh_db/user4.dbf' size 10m
extent management dictionary
minimum extent 100k                -- 모든 extents는 100k의 정수가 되어야 한다.
default storage (initial         100k -- 첫번째 extent의 크기
                        next          100k -- 두번째 이후 extent의 크기.
                                                -- 처음 이후에 되도록이면 initial과 같게 해줌
                        minextents 3     -- 최초 몇 개의 extent?
                        maxextents 10   -- 최대로 만들 수 있는 extent 무제한(unlimited)
                        pctincrease 50    -- 퍼센트 : 3번째 부터 extent의 성장 비율
                                                 -- 100k -> 100k -> 150k -> 225k
                        );

create table t1 (c1 number) tablespace users5;
create table t1 (c1 number) tablespace users5 storage (initial 150k next 150k);

단편화 (fragmentation)
: 세그먼트의 중간중간에 사용하지 않는 공간이 발생하는 것을 말한다.

문제점
- 테이블 FULL SCAN시 소요 시간 증가
- 인덱스 레벨이 깊어짐
- 디스크 I/O 증가 가능 (하나의 데이터 블록 조회로 적은 로우가 추출)
- 디스크 공간 낭비

  원인은?
    - 서로 다른 크기가 들락날락하면서 생긴다.

   해결책은?
    - LMT로 한다. (uniform을 셋팅하여 extent의 크기를 모두 고정시킨다.)
    - DMT일 경우 pctincrease옵션 0을 주고, minimum extents 100k로 특정 크기의 배수로 주도록 한다.


테이블 스페이스의 관리

- 이름 변경

SQL> alter tablespace "USER1" rename to "DDD";

※ 테이블스페이스명을 소문자일 경우 인식을 못함.
(X) alter tablespace "user1" rename to "DDD";

- 상태 변경

SQL> alter tablespace "USER1" read only;
SQL> alter tablespace "USER1" read write;
SQL> alter tablespace "USER1" offline normal;

- 크기 변경

SQL> alter tablespace "USER1" add datafile '/u01/app/oracle/oradata/jgh_db/USER2.dbf' size 10m;
-- 줄이는 것 불가능
SQL> alter database datafile '/u01/app/oracle/oradata/jgh_db/user1.dbf' resize 20m; -- 줄이는 것도 가능
SQL> alter database dafafile '/u01/app/oracle/oradata/jgh_db/user2.dbf' autoextend on next 10m maxsize 2g;
SQL> alter tablespace "USER1" nologging;

ASM
- Automatic Storage management
- 11g r2에서 다른 일반적인 파일도 들어올 수 있음.
- spreading, mirroring 가능

기타내용

테이블 디렉토리 : 클러스터의 다른 테이블의 위치 정보시 필요함.

로우 디렉토리 : (변경될 수 있는) 로우의 위치 정보(2kb)

로우 헤더 : 로우의 길이가 들어가 있음

online redo log file 존재의 주목적은?
- instance 복구
- commit 속도를 빠르게 한다.

테이블 스페이스의 종류
- permanant : 어떤 종류의 테이블 스페이스도 다 만들 수 있다.
- temp : temp전문 테이블 스페이스
- undo : undo전문 테이블 스페이스(9i부터)

insert : freelist + transaction slot이 필요함
update: transaction slot이 필요함

Bitmap?
- 비트의 맵. extents가 할당되면 1, 해제되면 0
- 부동산 앞의 지도와 같은 역할이라고 보면 이해하기 쉬움

'Oracle > Admin' 카테고리의 다른 글

Managing Schema Objects-1 (0)	2009.11.30
Administering User Security (0)	2009.11.27
2009년 11월 25일 수업내용 (0)	2009.11.25
2009년 11월 24일 수업내용 (0)	2009.11.24
Static Data Dictionary View vs Dynamic Performance View (2)	2009.11.24

Posted by 자수성가한 부자

2009년 11월 25일 수업내용

Database storage 관리
- control file
- redo log file
- data file

1. Control file

- control 파일을 추가하는 방법을 실습해보자.

파라미터를 변경한다.

SQL> alter system set control_files = '/u01/app/oracle/oradata/jgh_db/control01.ctl',
'/u01/app/oracle/oradata/jgh_db/control02.ctl',
'/u01/app/oracle/oradata/jgh_db/control03.ctl' scope = spfile;

shutdown 시킨다.(!!!!안할경우 파일이 깨질 가능성이 있음)

SQL> shutdown immediate

파일을 복사한다.

SQL> !cp /u01/app/oracle/oradata/jgh_db/control01.ctl /u01/app/oracle/oradata/jgh_db/control03.ctl

파일이 잘 복사되었는지 확인한다.

SQL> !ls /u01/app/oracle/oradata/jgh_db/control03.ctl

startup을 한다.

SQL> startup

잘 되었는지 확인해보자

SQL> select * from v$controlfile;
SQL> show parameter control

2. Redo log file

- redo log file을 추가하는 방법을 실습해보자.

현재 redo log 관련 내용을 확인해보자.

SQL> select * from v$log;
SQL> col member format a60;
SQL> select * from v$logfile;

     v$logfile의 status은 각 의미는 다음과 같다.
       - current : 현재 쓰고 있는 그룹
       - inactive : 언제든지 재이용할 수 있는 그룹
       - active : 지금 dbwr가 쓰고 있는 그룹

로그파일을 추가한다.

2개의 멤버가 있는 1개 그룹과 1개의 멤버가 있는 로그 파일을 추가한다.

SQL> alter database add logfile ('/u01/app/oracle/oradata/jgh_db/redo03_a.log',
'/u01/app/oracle/oradata/jgh_db/redo03_b.log') size 10m;
SQL> alter database add logfile '/u01/app/oracle/oradata/jgh_db/redo04_a.log' size 10m;

잘 추가되었는지 확인해보자.

SQL> select * from v$log;
SQL> select * from v$logfile;

강제로 log switch 발생시킨다.
(v$log의 status변경 : unused -> inactive)

SQL> alter system switch logfile

강제로 check point 발생
(v$log의 status변경 : active -> inactive로 변경)

SQL> alter system checkpoint;

마지막으로 멤버가 하나뿐인 그룹에 1개의 멤버를 추가한다.

SQL> alter database add logfile '/u01/app/oracle/oradata/jgh_db/redo04_a.log' size 10m to group 4;

리두 로그 멤버 삭제 및 그룹 삭제 :

1번 그룹, 2번 그룹을 alter system switch logfile 및 alter system checkpoint 명령을 이용해서 1번, 2번 그룹의 상태를 inactive로 만든다.

리두 로그를 삭제한다.
아래의 명령어는 control file에서 redo log file의 내용만 사라짐. os에는 파일이 남아 있다.
따라서 OS 명령으로 직접 파일을 삭제해야 한다. 주의할 것!!!!

멤버 파일을 삭제한다.

SQL>alter database DROP logfile MEMBER '/u01/app/oracle/oradata/jgh_db/redo01_a.log';

삭제가 잘 되었는지 확인해본다.(control파일에서 redo log부분만 사라짐)

SQL> select * from v$logfile where group# =1;

OS 명령으로 파일을 확인해본다.

SQL> !ls -l /u01/app/oracle/oradata/jgh_db/redo*

위에서 삭제했던 멤버의 파일을 삭제한다. (!!주의)

SQL> !rm /u01/app/oracle/oradata/jgh_db/redo01_a.log

그룹 삭제를 해본다.

SQL> alter database DROP logfile GROUP 1;
SQL> alter database DROP logfile GROUP 2;

OS내에 파일을 확인한다.

SQL> !ls -l /u01/app/oracle/oradata/jgh_db/redo*

위에서 지운 그룹의 파일을 지운다.

SQL> !rm /u01/app/oracle/oradata/ikdb/redo01_b.log
SQL> !rm /u01/app/oracle/oradata/ikdb/redo02_a.log
SQL> !rm /u01/app/oracle/oradata/ikdb/redo02_b.log

만약 잘못하여 파일을 지울 경우

SQL> !rm /u01/app/oracle/oradata/ikdb/redo03_a.log

스타트업 한다.

SQL> startup force

log file의 정보를 확인한다.

SQL> select * from v$logfile;

redo03_b.log의 파일을 redo03_a.log로 복사한다.

SQL> !cp /u01/app/oracle/oradata/ikdb/redo03_b.log /u01/app/oracle/oradata/jgh_db/redo03_a.log

log switch를 발생시킨다.

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

확인해보자.

SQL> select * from v$logfile;

3. Datafile 그리고 Tablespace

테이블 스페이스의 내용을 확인하기 편하도록 아래의 명령어를 파일에 저장해둔다.

-- 테이블 스페이스명, 블럭 크기, 상태, 내용의 정보를 확인
SQL>select tablespace_name, block_size, status, contents
        from dba_tablespaces;
SQL> save ts

-- 데이터 파일과 템프 파일확인
SQL> select file_name, tablespace_name from dba_data_files
         union all
         select file_name, tablespace_name from dba_temp_files;
SQL> save df

데이터베이스의 속성을 확인한다.(속성명과 속성값)

SQL> select PROPERTY_NAME, PROPERTY_VALUE
from database_properties;

테이블 스페이스를 추가한다.

SQL> create temporary tablespace temp_a tempfile '/u01/app/oracle/oradata/jgh_db/temp_a.tmp' size 10m;
SQL> create undo tablespace undo_a datafile '/u01/app/oracle/oradata/jgh_db/undo_a.dbf ' size 10m;
SQL> create tablespace users datafile '/u01/app/oracle/oradata/jgh_db/users.dbf ' size 10m;

테이블 스페이스가 추가된 것을 확인할 수 있다.

SQL> @ts
SQL> @df

디폴트 테이블스페이스와 템프 테이블 스페이스를 변경해준다.

SQL> alter database default tablespace users;
SQL> alter database default temporary tablespace temp_a;

잘 변경이 되었는지 확인해본다.

SQL> select PROPERTY_NAME, PROPERTY_VALUE from database_properties;

언두 파라미터 확인

SQL> show parameter undo

파라미터 파일을 변경한다.

SQL> alter system set undo_tablespace = undo_a scope=both;

데이터 블럭의 분해

1. 파일 헤더

2. 세그먼트 헤더

    - freelist
      : insert가능한 블럭 주소 시작, 끝이 들어있다.
      (동시에 너무 많은 유저가 insert를 하면 CPU, NETWORK, 메모리에 관계없이 대기 시간 길어짐
       -> 전체적 성능 저하 -> OWI로 분석 후 해결가능)
    - HWM
      : High Water Mark의 약자
      : full table scan의 기준이 된다. dba_tables로 확인 가능
       (물 증가 후 자국이 남는다.)

3. 블럭 헤더
   - 세그먼트 타입(테이블, 인덱스, ..)
   - 데이터 블럭 주소
   - 테이블 디렉토리
   - 로우 디렉토리
   - 트랜잭션 슬롯 : 트랜잭션당 하나씩 차지한다. undo의 주소가 남는다.
   - 위에서 아래로 채워짐

4. 로우 데이터
   - 실제 데이터가 저장됨.
   - 그림과 같이 아래에서 위로 채워진다.

참고 : oracle10gr2 메뉴얼 concept

'Oracle > Admin' 카테고리의 다른 글

Administering User Security (0)	2009.11.27
2009년 11월 26일 수업내용 (0)	2009.11.26
2009년 11월 24일 수업내용 (0)	2009.11.24
Static Data Dictionary View vs Dynamic Performance View (2)	2009.11.24
수동 DB 생성 / 네트워크 설정 (10gr2, linux) (0)	2009.11.24

Posted by 자수성가한 부자

2009년 11월 24일 수업내용

instance open까지의 단계

shutdown 명령어

shutdown에는 아래와 같이 4개의 옵션이 있다.
- abort
   (새로운 손님 안 받음. 먹고 있는 손님 내보냄. roll forward 과정이 있음.)
- immediate
   (새로운 손님 안 받음. 먹고 있는 손님 내보냄 -> DML을 끊고. 비정상적인 프로세스 정리)->생각보다 오랜 시간이 걸림
- transactional
   (새로운 손님 안 받음, 먹고 있는 손님 기다림)
- normal
   (default, 새로운 손님 안받음, 먹고 있는 손님 기다림,
    접속중인 session이 exit명령으로 나갈 경우 종료됨)

비정상종료(abort)
정상종료(immediate, transactional, normal)

sqlplus 접속시에 파일 실행 후에 접속하도록 할 수 있다.

다음의 내용을 따라해보면 알 수 있다.

a.sql 파일을 생성한다.

OS] vi a.sql

a.sql파일 내부에 넣을 내용

SQL> select * from scott.emp;
SQL> exit

다음의 명령을 실행한다.

OS] sqlplus 유저/암호 @a.sql

a.sql을 실행한 후 sqlplus에 접속한다.

parameter

- static parameter
   startup 이후에 바꿀 수 없는 parameter
   대표적인 static parameter : alter system set sga_max_size=264

- dynamic parameter
   startup 이후에도 바꿀 수 있는 parameter

parameter file

: instance 구성시에 필요한 파일로, initSID.ora, spfileSID.ora
파라미터 파일 읽는 순서 : spfileSID.ora -> spfile.ora -> initSID.ora -> 에러
pfile과 spfile이 둘다 없을 경우 startup시에 에러
(해결방법은 pfile, spfile을 생성 or startup시 파일 지정)
initSID.ora -> spfileSID.ora 가능
또한 spfileSID.ora -> initSID.ora도 가능

- pfile
     initSID.ora
     text파일
     alter system set으로 파라미터 변경시 메모리상에만 바꿈.
     파일의 내용은 안바뀜(수동으로 바꿔줘야 했음)

- spfile
      spfileSID.ora
      binary파일
      alter system set으로 명령을 쳐서 변경
      메모리와 파일 둘 다 바뀌도록 설정할 수 있음(SCOPE=both일 경우)

아무 위치나 아무 이름의 특정 파일 생성 후 startup 시에 pfile의 경로와 이름을 넣어주면
그 파일에 설정되어 있는 대로 instance가 생성됨

OS] sqlplus / as sysdba
SQL> startup pfile=경로/파일명

spfile로 시작했을 경우 아래의 커맨드를 치면 확인할 수 있다.
내용이 나오면 spfile로 시작한 경우 이다.

SQL> show parameter spfile

아래는 파라미터 관련 실습 내용이다.

# 파라미터 : Dynamic vs Static (spfile을 사용할 경우)

- Dynamic 파라미터의 변경

SQL> alter system set sga_target = 2G;
SQL> alter system set sga_target = 2G scope=both;
SQL> alter system set sga_target = 2G scope=memory;
SQL> alter system set sga_target = 2G scope=spfile;

- Static 파라미터의 변경

SQL> alter system set sga_max_size = 2G scope=spfile;

# 파라미터 : Dynamic vs Static (pfile을 사용할 경우)

- Dynamic 파라미터의 변경 : 명령으로 현재 인스턴스는 변경되지만 파일은 직접 수정해야 한다.

SQL> alter system set sga_target = 200m;
SQL> alter system set sga_target = 200m scope=both; -- ORA-32001: write to SPFILE requested but no SPFILE specified at startup
SQL> alter system set sga_target = 200m scope=memory;
SQL> alter system set sga_target = 200m scope=spfile; -- ORA-32001: write to SPFILE requested but no SPFILE specified at startup

- Static 파라미터의 변경 : 명령으로 수정이 불가능하며 직접 파일을 수정해야 한다.

SQL> alter system set sga_max_size = 200m scope=spfile; -- ORA-32001: write to SPFILE requested but no SPFILE specified at startup
SQL> alter system set sga_max_size = 200m; -- ORA-02095: specified initialization parameter cannot be modified

# 파라미터 파일 : Pfile(텍스트파일) vs Spfile(바이너리파일)

- 기본 위치에 있는 기본 이름의 파일로 기본 위치에 기본 이름의 파일 생성

SQL> create pfile from spfile;
SQL> create spfile from pfile;

- 원하는 위치에 원하는 이름의 파일 생성

SQL> create pfile='/home/oracle/a.txt' from spfile;

- 원하는 위치에 있는 원하는 파일을 이용해서 원하는 위치에 원하는 이름의 파일 생성

SQL> create spfile='$ORACLE_HOME/dbs/spfilea.ora' from pfile='/home/oracle/a.txt';

# Startup에 어떤 파라미터 파일을 사용하는가?

SQL> startup                              --> $ORACLE_HOME/dbs/spfileorcl.ora -> spfile.ora -> initorcl.ora -> 에러
SQL> startup pfile='/home/oracle/a.txt'   --> 원하는 pfile 이용
SQL> startup pfile='/home/oracle/b.txt'   --> 원하는 spfile 이용 : b.txt의 내용 : spfile='$ORACLE_HOME/dbs/spfilea.ora'

Diagnostic files(진단 파일)

- alertsid.log
   :무조건 생김. 전체 인스턴스 당 하나의 파일이 생김.
    위치 :BACKGROUND_DUMP_DUST에 정의된 위치
    끝없이 커지므로 가끔 지워줘야 함.

- sid_dbw0_pid.trc
   : 프로세스당 하나씩 남는다.
    dbw0대신에 다른 프로세스가 들어간다.
    위치는 BACKGROUND_DUMP_DUST에 정의된 위치
    주로 장애가 날 경우 생김

- sid_ora_pid.trc
   : 서버 프로세스가 남기는 로그로 두군데에 생긴다.
      1. BACKGROUND_DUMP_DUST : 에러시
      2. USER_DEMP_DEST              : 유저요청시

진단 파일의 위치를 알고 싶은 때 명령어

SQL> show parameter dump;

alert파일을 external테이블로 연결하기
참고 : http://blog.naver.com/orapybubu?Redirect=Log&logNo=40050729230

기타사항

RESTRICTED 관련 내용 넣을 것

show parameter sga;

tail -f $ORACLE_HOME/rdbms/log/alertorcl.log

X$로 시작되는 internal테이블
-> parameter, instance의 활동, control 파일의 내용으로 채워져 있는 테이블

현재 instance의 상태 확인

SQL> select status from v$instance;

'Oracle > Admin' 카테고리의 다른 글

2009년 11월 26일 수업내용 (0)	2009.11.26
2009년 11월 25일 수업내용 (0)	2009.11.25
Static Data Dictionary View vs Dynamic Performance View (2)	2009.11.24
수동 DB 생성 / 네트워크 설정 (10gr2, linux) (0)	2009.11.24
2009년 11월 23일 수업내용 (0)	2009.11.23

Posted by 자수성가한 부자

Static Data Dictionary View vs Dynamic Performance View

Static Data Dictionary View

- 데이터베이스에 존재하는 오브젝트 및 기타 정보에 대한 내용을 조회할 수 있는 뷰
  - 거의 바뀌지 않음
  - open시에만 이용가능(nomount, mount때는 이용 불가능)
- 정보의 출처는 internal table(obj$, col$, users$ 등)이다.
- 종류
       USER_* : 소유
                    USER_OBJECTS, USER_TABLES, USER_TAB_COLUMNS,
                    USER_CONSTARINTS, USER_CONS_COLUMNS, USER_VIEWS,
                    USER_SEQUENCES, USER_SYNONYMS
       ALL_*   : 접근 가능
       DBA_*   : 모든 , DBA라면 많이 알아야 하는 부분

DBA_OBJECTS,

- 데이터의 생명이 instance와 무관함

sqlplus에서 확인해보자

OS] sqlplus / as sysdba

SQL> shutdown abort;

SQL> startup nomount;

SQL> select * from users;

SQL> alter database mount;

SQL> select * from users;

SQL> alter database open;

SQL> select * from users;

Dynamic Performance View

- 메모리 상태 및 현재 세션에 대한 정보를 확인할 수 있는 뷰
- v$로 시작한다.
- 대표적인 view : v$sysstat, v$transaction, v$log,
- 끊임없이 내용이 바뀜(v$transaction 등)
- nomount, mount, open에서도 확인 가능
- Data의 생명이 대체로 instance와 동일 (session과 연관된 것 제외)
startup에서 shutdown까지의 내용이 저장되어 있음
- 정보의 출처는 X$로 시작하는 테이블이다.
- 전체 v$목록은 v$fixed_view_definition로 볼 수 있다.

SQL> select * from v$fixed_view_definition;

주요 Tunning 대상 질의 쿼리문 중 하나
(참고 : 오라클 교재, WS1. Less04_Instance_TB3.ppt 33페이지)

SQL> select sql_text, executions
from v$sql
where cpu_time > 200000;

'Oracle > Admin' 카테고리의 다른 글

2009년 11월 25일 수업내용 (0)	2009.11.25
2009년 11월 24일 수업내용 (0)	2009.11.24
수동 DB 생성 / 네트워크 설정 (10gr2, linux) (0)	2009.11.24
2009년 11월 23일 수업내용 (0)	2009.11.23
Explain Plan과 Execution Plan의 차이 (0)	2009.11.22

Posted by 자수성가한 부자

수동 DB 생성 / 네트워크 설정 (10gr2, linux)

Database 생성 방식의 종류에는 두가지가 있다.
1. DBCA이용(오라클 교재 참고할 것 3장 초반, dbca실행은 os커맨드창에서 dbca를 실행시키면 됨)
2. 수동으로 생성

여기에서는 수동으로 linux에 Database를 생성하는 방법을 알아보도록 하겠다.
(OS: linux, oracle ver.: 10gr2
Windows는 첨부파일을 참고할 것)

1. 디렉토리 생성한다.
   (붉은색으로 되어 있는 부분은 생성하고 싶은 database명과 instance명이다.
    자신이 원하는 이름으로 해주면 되겠다.
    참고로 보통 database명과 instance명은 같은 이름으로 해준다.)

OS] mkdir $ORACLE_BASE/oradata/jgh_db

2. parameter 파일 생성한다. (참고로 parameter파일은 instance의 구성과 관계가 있다.)

OS] export ORACLE_SID=jgh_db
OS] vi $ORACLE_HOME/dbs/initjgh_db.ora

아래는 파일에 들어갈 내용이다.

db_name       = jgh_db
instance_name = jgh_db
compatible    = 10.2.0
processes     = 100

undo_management = auto
undo_tablespace = undotbs01

db_cache_size    = 64m
shared_pool_size = 72m
db_block_size    = 4096

control_files = ('$ORACLE_BASE/oradata/jgh_db/control01.ctl',
                     '$ORACLE_BASE/oradata/jgh_db/control02.ctl')

remote_login_passwordfile = exclusive

3. nomount상태로 시작한다.

OS] sqlplus / as sysdba
SQL> startup nomount

4. database를 생성한다.
- 실제 Database 를 생성하는 단계이며, Control File / Redo Log File / Data File 이 생성된다
- 생성 후 OPEN 상태로 변경되어 $ORACLE_HOME/rdbms/admin/sql.bsg 를 자동 실행한다
- $ORACLE_HOME/rdbms/admin/sql.bsg 의 실행을 통해 TAB$,COL$ 등의 Internal Table을 생성한다

create database jgh_db
logfile group 1 ('$ORACLE_BASE/oradata/jgh_db/redo01_a.log',
                      '$ORACLE_BASE/oradata/jgh_db/redo01_b.log') size 20m,
         group 2 ('$ORACLE_BASE/oradata/jgh_db/redo02_a.log',
                      '$ORACLE_BASE/oradata/jgh_db/redo02_b.log') size 20m
datafile '$ORACLE_BASE/oradata/jgh_db/system01.dbf' size 200m autoextend on next 20m maxsize unlimited
sysaux datafile '$ORACLE_BASE/oradata/jgh_db/sysaux01.dbf' size 200m autoextend on next 20m maxsize unlimited
undo tablespace undotbs01 datafile '$ORACLE_BASE/oradata/jgh_db/undotbs01.dbf' size 100m autoextend on next 20m maxsize 2G
default temporary tablespace temp tempfile '$ORACLE_BASE/oradata/jgh_db/temp01.tmp' size 20m autoextend on next 20m maxsize 2G;

5. sys, system 유저의 패스워드를 변경한다.

SQL> alter user sys identified by oracle;
SQL> alter user system identified by oracle;

6. data dictionary, pl/sql, product user profile 테이블 및 관련 프로시져 생성을 위한 작업을 해준다.

SQL> ed after_db_create.sql

아래는 파일에 들어갈 내용이다.

conn sys/oracle as sysdba
@?/rdbms/admin/catalog.sql            -- data dictionary 생성
@?/rdbms/admin/catproc.sql            -- pl/sql 환경 구성

conn system/oracle
@?/sqlplus/admin/pupbld.sql            -- product user profile테이블 및 관련 프로시져 생성

파일을 실행한다. 여기에서 20분가량의 시간이 걸린다.

SQL> @ after_db_create.sql

SQL> exit

이걸로 database 생성은 잘 끝났다. 잘 생성되었는지 테스트해보자.

OS] export ORACLE_SID=jgh_db
OS] sqlplus / as sysdba
SQL> select instance_name from v$instance;
SQL> shutdown abort
SQL> startup

다음은 네트워크 설정이다.
원격지에서 제어하기 위해서 필요한 설정이다.

1. 리스너를 정지한다.

OS] lsnrctl stop

2. listener.ora 파일을 편집한다.

OS] vi $ORACLE_HOME/network/admin/listener.ora

아래의 붉은 부분을 추가해준다.

LISTENER =
(DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1))
      (ADDRESS = (PROTOCOL = TCP)(HOST = localhost.localdomain)(PORT = 1521))
    )
)

SID_LIST_LISTENER =
(SID_LIST =
    (SID_DESC =
      (SID_NAME = PLSExtProc)
      (ORACLE_HOME = /home/oracle/product/10.2.0/db_1)
      (PROGRAM = extproc)
    )
    (SID_DESC =
      (SID_NAME = orcl)
      (ORACLE_HOME = /home/oracle/product/10.2.0/db_1)
      (GLOBAL_DBNAME = orcl)
    )
    (SID_DESC =
      (SID_NAME = jgh_db)
      (ORACLE_HOME = /home/oracle/product/10.2.0/db_1)
      (GLOBAL_DBNAME = jgh_db)
    )
)

3. 리스너를 시작한다.

OS] lsnrctl start

4. tnsnames.ora파일을 편집한다.(isqlplus에 접속할 수 있도록 설정)

OS] vi $ORACLE_HOME/network/admin/tnsnames.ora

붉은 부분을 추가해준다.

ORCL =
(DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = localhost.localdomain)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = orcl)
    )
)
jgh_db =
(DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = localhost.localdomain)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = jgh_db)
    )
)

5. 패스워드 파일을 생성한다.

OS] ls $ORACLE_HOME/dbs
OS] orapwd file=$ORACLE_HOME/dbs/orapwjgh_db password=oracle entries=5

여기까지해서 네트워크 세팅이 완료되었다.
잘 되었는지 테스트해보자.

OS] tnsping orcl
OS] tnsping jgh_db

여기까지 수동으로 DB를 생성하고, 네트워크 세팅하는 것을 알아보았다.

참고 : http://cafe.naver.com/gseducation/87
http://www.urbantree.wo.tc/entry/3
http://blog.naver.com/enter128

'Oracle > Admin' 카테고리의 다른 글

2009년 11월 24일 수업내용 (0)	2009.11.24
Static Data Dictionary View vs Dynamic Performance View (2)	2009.11.24
2009년 11월 23일 수업내용 (0)	2009.11.23
Explain Plan과 Execution Plan의 차이 (0)	2009.11.22
linux4에 oracle10gR2 or oracle11gR2 설치 (0)	2009.11.22

Posted by 자수성가한 부자

2009년 11월 23일 수업내용

CR블럭

데이터베이스 버퍼 캐쉬에 존재하는 블럭으로 읽기 일관성을 위해 존재한다.
원본데이터의 복사본

아카이버는 언제 리두 로그파일을 복사할까?

로그 스위치를 하면 바로 동작한다.
예를 들면 (온라인)리두 로그 파일이 1, 2, 3 이렇게 3개 존재할 경우, 1에서 2로 바뀔때, 또는 2에서 3으로 바뀔 때
(오프라인)리두 로그 파일로 복사를 한다.

DBWR는 언제 데이터버퍼 캐쉬의 내용을 파일로 내려쓸까?

아래의 9가지 중 하나에 속할 때 내려쓴다.

- Checkpoint : shutdown, log switch, fast_start_mttr_target..., alter system checkpoint
- Dirty buffers’ threshold
- No free buffers
- Timeout
- RAC ping request
- Tablespace OFFLINE
- Tablespace READ ONLY
- Tablespace BEGIN BACKUP
- Table drop or truncate

LGWR가 리두 로그 버퍼의 내용을 리두 로그 파일로 내려 쓸때는?

총 13가지 인데,
- DBWR가 내려쓰기 전(9가지)
- 3분의 1이 사용되었을 때
- 리두 로그 버퍼가 1M가 찼을 때
- commit
- timeout (default는 3초)

OFA란?

:Optimal Flexible Architecture의 약자로,
오라클 핵심 개발자 몇명이 선호하는 파일 배치 방식이다. 오라클 나름의 기준의 디렉토리 및 파일의 배치를 말한다.

'Oracle > Admin' 카테고리의 다른 글

Static Data Dictionary View vs Dynamic Performance View (2)	2009.11.24
수동 DB 생성 / 네트워크 설정 (10gr2, linux) (0)	2009.11.24
Explain Plan과 Execution Plan의 차이 (0)	2009.11.22
linux4에 oracle10gR2 or oracle11gR2 설치 (0)	2009.11.22
grid computing (0)	2009.11.20

Posted by 자수성가한 부자

Explain Plan과 Execution Plan의 차이

Explain Plan(예측 실행 계획)

explain plan(예측 실행 계획)을 조회하는 가장 일반적인 방법은 아래와 같다.

explain plan for
select .....
;

select *
from table(dbms_xplan.display);

※ 예측 실행 계획을 볼때는 dbms_xplan.display를 이용할 것
(sqlplus에서 set autot on으로 이용하는 방법도 있지만 10gR2이후 버전부터는
둘다(dbms_xplan.display, set autot on) 같은 쿼리를 이용하기 때문에...)

Execution Plan(실행계획)

오라클에서 제공하는 실행 계획에는 총 5가지가 존재한다.

실행 계획의 종류

1. 예측 실행 계획 : Plan Table상에 존재. explain plan 명령 이용
2. 실제 실행 계획 : Shared Pool에 존재. v$sql_plan
3. 과거 실행 계획 : AWR에 존재. dba_hist_sql_plan
4. Tuning Set에 있는 실행 계획 : Tuning Advisor에 의해 생성된 실행 계획
5. Baseline에 있는 실행 계획 : SPM에 의해 관리되는 실행 계획

실행 계획의 구성요소

1. 단계별 Operation
2. Predicate(조건절) 정보
3. Query Block Name 정보
4. Outline 정보
5. Column Projection 정보

※더 자세한 내용은 다음의 책을 참조할 것
http://book.interpark.com/product/BookDisplay.do?_method=Detail&sc.shopNo=0000400000&sc.di
spNo=&sc.prdNo=201787078&bsch_sdisbook

관련내용 : http://121.254.172.39:8080/pls/apex/f?p=101:11:0::::P11_QUESTION_ID:4452200346716146

'Oracle > Admin' 카테고리의 다른 글

수동 DB 생성 / 네트워크 설정 (10gr2, linux) (0)	2009.11.24
2009년 11월 23일 수업내용 (0)	2009.11.23
linux4에 oracle10gR2 or oracle11gR2 설치 (0)	2009.11.22
grid computing (0)	2009.11.20
Query 실행순서(update) (0)	2009.11.19

Posted by 자수성가한 부자

자수성가한 부자

'Oracle'에 해당되는 글 219건

trigger(primary key & foreign key 관련)

'Oracle > PL_SQL' 카테고리의 다른 글

Administering User Security

'Oracle > Admin' 카테고리의 다른 글

Enqueue vs Latch

'Oracle > 용어정리' 카테고리의 다른 글

2009년 11월 26일 수업내용

'Oracle > Admin' 카테고리의 다른 글

2009년 11월 25일 수업내용

'Oracle > Admin' 카테고리의 다른 글

2009년 11월 24일 수업내용

'Oracle > Admin' 카테고리의 다른 글

Static Data Dictionary View vs Dynamic Performance View

'Oracle > Admin' 카테고리의 다른 글

수동 DB 생성 / 네트워크 설정 (10gr2, linux)

'Oracle > Admin' 카테고리의 다른 글

2009년 11월 23일 수업내용

'Oracle > Admin' 카테고리의 다른 글

Explain Plan과 Execution Plan의 차이

'Oracle > Admin' 카테고리의 다른 글

카테고리

최근에 올라온 글

달력

링크

티스토리툴바