|
[ArchiveLog]ArchiveLog 에 관하여
=======
아카이브
=======
1. NOARCHIVE MODE에서의 실행
- 온라인 리두로그의 ARchiving기능이 비활성돤다는 의미,즉 리두로그의 채워진 그룹이 비활성화되어 로그스위치에서 체크Point가 완료되면 그룹은 LGWR에 의해 재사용이 가능한 상태가 된다.
- 디스크 고장시에는 DB를 보호하지 못하지만 인스턴스 실패시에는 DB를 보호한다. 즉 온라인 리두로그에 저장된 최근의 변경사항만이 DB 복구에 이용된다. 즉 완전히 복구 하는게 아니라 최근에 DB전체를 백업했을때의 상태로만 복구가 가능하다.
- 온라인 TableSpace BAckUp은 수행할수 없다. 그러므로 정기적으로 Cold BackUp(DB를 ShutDown시킨후 DataFile,RedoLog,Control File등을 백업)을 해야 한다.
2. ArchiveLog Mode에서의 실행
- 온라인 리두로그의 Archiving 기능을 활성화 할수 있다. 리두로그 그룹이 비활성화되고 로그스위치가 발생한 후에 프로세스는 채워진 그룹을 아카이브한다. 아카이브를 수행하는 프로세스는 비활성그룹 그룹 아카이브를 위해 Access할수 있기 전에는 로그스위치의 체크포인트가 끝나기를 기다릴 필요가 없다.
- 인스턴스 실패뿐 아니라 디스크 고장등의 상황에서도 DataBase의 복구가 가능하다.
- DataBase 전체나 일부를 백업하는 중에도 DB를 Open하여 사용할수 있으며, Archive를 위해 별도의 관리가 필요하다. 즉 REDOLOG의 Archive된 파일을 저장할 DISK나
또는 Tape등이 필요하다. 또한 자동으로 Archive를 할건지 아니면 수동으로 할건지를 정해야 한다.
- 참고로 Redo LOG와의 경합을 줄이기 위해 Archive Destination은 RedoLOG와는 다른 Device로 하는것이 좋다.
- Archive Processor의 경우 대부분의 시스템성능에 영향을 주지 않는다. 그러나 대규모인 경우 영향을 줄수도 있슴. 대규모인 경우 아카이브 기능을 조절하여 아카이브를 가능한 느리게 수행하거나 , 시스템 성능이 그다지 저하되지 않는 범위내에서 아카이브를 되도록 빨리 돌릴수 있다. LOG_ARCHIVE_BUFFERS(아카이브에 할당되는 Buffer
수), LOG_ARCHIVE_BUFFER_SIZE(각버퍼의 size)를 조절해 줘야 한다.
- 시스템에 리두로그를 기다리지 않는 범위내에서 가능한 느리게 아카이브 작업을 할려면 아카이브 버퍼수를 1로, 각각의 버퍼 크기를 최대로 설정하여야 한다. 만약 Archiving을 Tape로 할경우 성능을 향상 시킬려면 아카이브 프로세서가 출력로그 에 쓰는 동시에 아카이브로그를 읽을수 있도록 여로개의 아카이브 버퍼를 사용한다.
- Archive 상태 정보를 보기위해서는
a. select log_mode from v$database;에서 현재 DB의 Mode를 확인하며,
b. v$archive, v$log등의 뷰를 통해 정보를 볼수도 있으며
c. svrmgr>archive lof list; 라는 명령을 통해 볼수도 있다.
===========
아카이브(2)
===========
1. DataBase의 Archive Mode변경
- DB Instance를 종료한다.
svrmgr>shutdown immediate;
svrmgr>startup ;
svrmgr>shutdown normal;
- DB를 백업한다.
- DB를 OPEN하지 말고 Mount만 한다.
svrmgr>startup mount;
- svrmgr>alter database archivelog;
- 참고로 수동으로 아카이브 할경우에는 아래와 같이 한다.
Svrmgr>alter system archive log all;
- 자동으로 아카이브 할경우 아카이브 기능을 화성화한다.(initSID.ora File에 추가)
(1) LOG_ARCHIVE_START = TRUE
* ARCH process 가 기동
* log switch 발생시 automatic archive를 수행한다. 만약 이parametrer가
false이면 manual archive를 실시하여야 한다.
(2) LOG_ARCHIVE_DEST =
/home/oracle7/dbs/archive_file/arc
* archive장소의 디렉토리와 확장자를 포함하지 않는 파일명을 지정
* 여기에서 archive_file까지는 directory이며 마지막에 있는
arc는 archive log file의 initial명이다.
(3) LOG_ARCHIVE_FORMAT = %s.log
* archive file의 확장자와 log sequence번호의 형식을 지정
* 이는 (2)에서 정의된 archive log의 initial file명과 함께 나타난다.
[ 예 ] arc123.log, arc124.log (123과 124는 log sequence number 이다.)
와 같은 형태의 화일이 생성된다.
[스키마개체관리]PCTFREE,PCTUSED에 관하여...
===============================
Schema개체 관리(각종매개변수)
===============================
1. Data Block영역의 사용되는 방법지정
a. PCTFREE 매개 변수
- Data Block의 일부를 그블록의 행에대한 갱신용으로 예약하는데 사용한다.
- Create Table 명령어에 pctfree 20등의 형태로 지정
즉 각 Data Block의 20% 정도를 사용가능한 빈영역으로 유지하여 작 블록에 있는 행을 갱신하는데 사용한다는 의미, 일반적인 Varchar2 Column은 가변 Column이기에 꽉 찰수도 있고 1 Byte만 값이 들 오 올수도 있다. 그러므로 변경이 주인 Table의 경우 PCTFREE매개변수를 신경써야죠.Default는 10% 이죠
- 작은값의 PCTFREE
기존 Table의 행확장을 위해 적은 공간을 예약
Insert로 블록을 완벽하게 채울수 있다.
Table이나 Index에 대한 전체 Data가 더 적은 블록(불록당 더많은 해또는 입력항목)에 저장되므로 영역을 절약할수 있다.
- 큰값의 PCTFREE
기존의 Table행을 갱신하려면 더많은 공간을 예약
삽입된 Data에 비해 더많은 블록이 필요할수도 있다.
행조작을 자주 체인화 할수 없으므로 갱신 수행능력이 향상된다. 즉 자주 갱신되는 Table의 경우 큰값이 요구된다.
- Index의 PCTFREE
* 초기 인덱스를 생성할때만 PCTFREE를 지정할수 있다.
b. PCTUSED 매개변수
- PCTFREE값에 의해 블록이 채워지면 사용가능한 블록의 백분율이 PCTUSED값보다
작아야지만 새로운 행을 삽입할수 있다.
- Create Table명령에 pctused 40 이라고 지정했다면 블록의 PCTFREE영역에 도달한후 PCTUSED 사용가능한 블록이 40% 미만인경우에는 Insert할수 없다는 애기임, Default응 40%임
- 적은값의 PCTUSED
PCTUSED의 값이 사용된 영역의 백분율보다 작아졌을 때 블록을 빈목록으로 이동하기 위해 UPDATE나 DELETE 명령문을 수행하는 수행비용이 감소한다.
DataBase안에서 사용되지 않은 영역이 증가
- 큰값의 PCTUSED
영역의 효율성이 향상됨
Insert와 Update 수행비용이 증가함
c. PCTUSED와 PCTFREE
- PCTFREE와 PCTUSED값의 합은 100보다 적거나 같아야 한다.
- 합이 100이면 PCTFREE에 지정된 영역만큼 유지하며 프로세싱 비용이 가장 높다.
- 블록 OverHead는 PCTUSED나 PCTFREE 계산에 포함되지 않음.
- 100과 PCTFREE와 PCTUSED의 합간 차이가 적을수록 영역사용면에서 효율적임
2. PCTFREE와 PCTUSED사용 예
a. 행의 크기를 증가시키는 Update명령문을 공통적으로 수행
PCTFREE 20, PCTUSED 40
갱신되는 행에대해 늘어나는 행에 충분한 여유를 주려고 PCTFREE를 20으로 설정 PCTFREE를 40으로주어 고도의 갱신 작업을 하는동안 프로세싱을 줄어들게하여 성능이 향상됨
b. 대부분의 Insert와 Delete,그리고 행의 크기가 늘지않는 Update
PCTFREE 5, PCTUSED 60
Update시 행의 크기를 크게 증가시키지 않으므로 PCTFREE 5로 설정, 그리고 PCTUSED를 60으로 설정하면 DELETE명령문에 의해 빈영역을 곧 사용하므로 프로세싱은 최소화된다.
c. Table이 매우커 저장영역이 주관심이며, 대부분 읽기전용 Transaction을 처리한다.
PCTFREE 5, PCRUSED 90
Table이 커서 블록을 완전히 채우려고 하므로 PCTFREE를 5로 설정
[스키마개체관리]저장영역 매개변수(Storage-Clause Option)에관하여
=========================================================================================
1. 저장영역 매개변수(Create Table/Cluster/Index/RollBackSegment/TableSpace등등에서 사용)
=========================================================================================
a. Initial
- Segment가 생성될때 할당될 때 첫번째 확장영역의 바이트 크기
- 기본:5 datablock, 최소:2 datablock, 최대:OS마다 틀림
- 킬로미터와 메가바이트를 나타내는 K,M을 사용가능하다.
- 2 DataBlock보다 작은값은 DB_Block_Size 매개변수에 따라 데이터블록 크기의 다음 배수로 반올림된다.
- 예를들어 데이터 블록 크기가 2048 바이트라면 테이블스페이스의 Initial저장영역의 기본값은 10240바이트가 된다. 이 DataBase에서 TableSpace를 생성하고 initial을 20000바이트라고 하면 자동으로 20480(10 데이터블록)으로 반올림된다.
b. Next
- Segment에 대해 할당된 다음영역의 증가량의 바이트 크기
- 두번째 확장영역은 NEXT의 원래 크기와 동일하며 다음부터의 NEXT는
(1+PCTINCREASE/100)과 Next의 이전크기를 곱한 크기로 설정된다.
c. MAXEXTENTS
- 첫번째 확장영역을 포함한 전체확장 영역의 개수의 최대값
- 기본:OS에 따라 다름, 최소:1, 최대:무제한
d. MINEXTENTS
- Segment가 생성될때 할당되는 전체확장영역의 개수
- 기본:1 , 최소:1, 최대:OS마다 다름
- 값이 1보다 크면 INITIAL, NEXT, PCTINCREASE를 사용하여 생성할 때 지정한 수만큼의 증가된 확
장 영영이 할당됨
- RollBack Segment에 대한 MINEXTENTS값은 2임.
e. PCTINCREASE
- SEgment에 할당된 마지막 증가량의 확장영역에 대해 각 증가량의 확장영역이 믈어날 비율
- 기본:50(%), 최소:0(%), 최대:OS마다 틀림
- 0이면 모든 확장영역의 크기는 동일
- 0보다 크면 NEXT가 계산될때마다 PCTINCREASE만큼 늘어난다. 음수는 될수없다.
- RollBack Segment에 대한 PCTINCRESE는 0이다.
- Segment의 PCTINCREASE를 변경하면 시그먼트의 현재 NEXT값은 변경되지 않으며 이후의 NEXT 값들이 영향을 받음
f. INITRANS
- 동시에 DataBlock의 행을 Access하는 초기 Transaction 입력항목에 대해 미리 할당된 영역을 예약
- Table에 대한 기본값은 1, 클러스터와 인덱스는 2
g. MAXTRANS
- 다중 트랜잭션이 동시에 동일한 블록에 있는 행을 Access할 때 블록의 각 Transaction 입력 항목에 대한 영역이 할당됨.
- INITRANS에 의해 예약된 영역이 고갈되면 추가 Transaction 입력항목에 대한 영역은 사
용가능한 블록의 빈영역에 할당된다. 일단 할당되면 이영역은 블록헤더의 영구적인 부분
이 된다. 따라서 MAXTRANS를 사용하여 데이터 블록의 Transaction입력항목에 대해 할당할수 있는 빈영역을 제한할수 있다.
- MAXTRANS값이 너무 작으면 이 한계값에 의해 중단된 Transaction은 다른 Transaction 이 완전히 수행하고 빈 트랜잭션 입력항목 영역이 생길 때 까지 기다려야 한다. 즉 MAXTRANS가 3이고 4번째 Transaction이 세개의 Transaction에 의해 이미 Access되고 있는 블록을 Access하려고 하면 , 세개중 하나가 Commit되거나 RollBack될때까지 기다 려야 한다.
- 기본값은 블록크기에 대한 운영체제에 따른 함수이며, 최대 255를 초과하지 않는다.
h. 저장영역 매개변수의 사용예
- create table emp (
emp_id varchar2(4) not null,
emp_nm varchar2(12) null,
…)
pctfree 10
pctused 50
storage
(initial 100k next 100k
minextents 2 maxextents 10 pctincrease 0);
- 매개변수의 수정은 Table인 경우 아래와 같이 한다.
Alter table emp storage (next 50k);
[스키마개체관리]저장영역 할당해제에 관하여...
=================
1. 영역할당해제
=================
a. 세그먼트(Table,Index,Cluster)에서 사용되지 않는 할당영역을 해제하는 명령은 다음과 같다.
- alter table emp dealocate unused keep 500k;
Keep뒤에 값을 주면 보존하겠다는 의미임(남아있는 사용되지않는 영역이 해제될때도 남아있다.즉 실재 사용되는 영역이외에 500k를 남기겠다는 의미) 남아있는 확장영역의 수가 MINEXTENTS보다 작다면
MAXEXTENTS값은 새로운 수를 반영하기 위해 변경된다. 초기확장 영역이 적으면 INITIAL값은 이를 반영하기위해 변경된다. 만역 KEEP절을 지정하지 않으면 모든 사용되지 않는 영역은 INITIAL값과 MINEXTENTS가 보존되는한 해제된다.따라서 MINEXTENTS경계내에서 고수위가 발생해도 MINEXTENTS값은 유지되며 INITIAL값은 변경 되지 않는다.
- 예를들어 emp Table이 3개의 확장영역(10k ,20k 30k)로 구성이 되어있고 고수위( DBMS_SPACE Package에서 현재 Segment의 고수위 값을 알수 있으며, UNUSED_SPACE프러시져를 이용하여 사용하지 않는 영역을 알수있다.)는 두번째 확장영역의 가운데 있다고 하자 즉 40k정도는 사용하지 않는다는 애기임, 다음과 같은 명령을 입력하면
alter table emp deallocate unused;
2개의 확장영역이 남으며 세번째 확장 영역은 사라지며 두번째 확장 영역의 크기는 10k 로 남는다. 만약 alter table emp deallocate unused keep 10k;라고 하면 2개의 확장영역이 남으며 두번째 확장영역의 크긴 20k가 돤다.
[Lock] Oracle의 Lock에 관하여(1)...
Oracle이 채택한 유일한 Data Lock은 row-level Lock이다. row lock의 갯수는 제한이 없으며, Oracle은 row-livel부터 그이상의 Table Lock으로 escalate하지 않습니다. Row Locking은 최대로 가능한 미세한 Locking을 제공하며 , 가장 가능한 concurrency와 throughput을 제공한다.
Multiversion concurrency control과 row-level locking의 결합은 동일한 row를 access할때에 data에 대해서 user들이 경쟁할때 의미가 있다.
특히:
* data의 reader들이 동일한 data row들의 writer들을 기다리지 않는다.
* data의 writer들은 동일한 data row들의 reader들을 기다리지 않는다.
(reader에 대해서 특별히 Lock을 요구하는, select ...for update를 사용하지 않는다면)
* Writer들이 동시에 동일한 row를 갱신하려고 한다면 다른 Writer들은 기다려야 한다.
참고:data의 reader들은 분산 Trasaction들을 pending하는 일부 특별한 경우에 동일한 Data Block들의 writer들을 기다려야 할수도 있다.
모든 경우에 Oracle은 SQL수행시에 자동으로 Lock을 획득하며, User는 자세한 부분을 생각하지 않아도 된다. Oracle은 또한 User가 data를 Manual로 Locking하는것을 허용한다.
1.Trnasaction과 Data Concurrency
- Oracle은 locking 메커니즘을 사용하는 트랜잭션사이에 data concurrency와 integrity를 제공할 수 있다. Oracle의 lock 메커니즘은 transaction control과 밀접하기에, application Designer들은 적당히 트랜잭션을 정의하기만 하면 되고, Oracle은 자동으로 Lock을 관리해 준다.
2. Duration of Locks
- Transaction에 의해 걸린 Lock은 다른 동시수행 Transaction으로 부터의 파괴적인 간섭(dirty reads,lost update, 파괴적인 DDL Operation)을 막기위해, Transaction기간 동안 유지된다. 하나의 Transaction의 SQL문장에 의해서 변경된 data는 그 트랜잭션이 Commit된후 시작된 다른 Transaction에 의해서 볼수있다.
Oracle의 트랜잭션내의 문장에 의해 걸린 Lock들은 해당 트랜잭션이 커밋되거나 롤백된후에 해제된다. Oracle은 또한 SavePoint까지 RollBack되었을때 savepoint후에 걸린 Lock들을 해제한다.
3.DeadLock
- Oracle은 자동으로 DeadLock을 발견하고 deadlock과 관련된 문장중의 하나를 rollback하며, 충돌되는 row lock들의 집합중의 하나를 해제한다.또한 Rollback된 트랜잭션은 statement-level rollback을 수행했다는 message를 받는다. statement rollback은 transaction이 deadlock에 걸렸다는 것을 나타낸다. 일반적으로 명백하게 rollbacl되었다는 메시지를 받은 transaction은 기다린후에 rolled-back statement를 수행한다. deadlock은 대부분 트랜잭션이 명백하게 default lock을 무시한때 자주 발생한다. Oracle 자체가 lock escalate하지않고 query들에 대해서 read lock을 사용하지만 row-level locking을 사용함으로서 deadlock은 드물게 발생한다.
4. avoid deadlock
- multi-table deadlock들은 만약 동일한 Table을 Access하는 트랜잭션이 서로 동일한 순서로 이 Table에 묵시적으로 명백한 lock을 건다면 일반적으로 피할수 있다. 예를들면 개발자들이 Master Table과 Detail Table모두를 변경한다면 ,먼저 master쪽에 lock을 걸고, 그다음에 detail쪽에 lock 을 걸어야 할것이다.
[Lock] Oracle의 Lock에 관하여(2)...
1. Locks의 형태
- Oracle은 자동으로 data에 대한 concurrent access하기위해서 여러종류의 lock을 사용하며,user 들 사이에 파괴적인 상호작용을 방지한다. 또한 Oracle은 다른 트랜잭션들이 동일한 자원에대한 exclusive access를 요구하는것을 방지하기 위해 transaction과 관련된 자원들을 자동으로 lock을 건다.이 lock은 어떤 event가 발생하면 , 그리고 그 transaction이 더이상 자원을 요구하디 않을때 자동으로 해제한다. 참고로 프로그래머들이 명심햐야할 사항은 모든 SQL에 대해서 묵시적인 lock이 발생하므로 , 어떠한 자원에 대해서고 명백한 locking이 필요하지 않다. Operation 전체에 걸쳐서, Oracle은 lock이 걸린 자원과 수행된 operation에 따라서 여러 level의 restrictiveness에 여러형태의 lock을 자동으로 건다. 일반적으로 Oracle lock은 다음의 분류중의 하나가 걸린다.
a. data locks(DML locks)
data보호를 위한 locking, 예를들면 table lock은 전체 table에대해 lock을 걸지만 row locks은 선택된 row들에 lock을 건다.
b.dictionary locks(DDL locks)
Object들의 Structure를 보호하기위한 lock, 즉 table과 row들의 정의를 보관한다.
c. internal locks and latches
Internal lock과 latch들은 datafile들과 같은 internal data structure를 보호하며 internal lock과 latches는 완전히 자동이다.
d.distributed locks
distributed locks은 여러 다양한 Oracle Parallel Server사이의 분산된 data와 또다른 자원이 consistent를 유지하는것을 보존한다. distributed locks은 트랜잭션보다는 Instance에 의해서 걸린다. Oracle Parellel Server사이의 Instance는 자원의 현재 상태를 서로 전달한다.
e.Parallel cache management(PCM) locks
Parallel cache management(PCM) locks은 buffer cache내에서 하나 이상의 data block(table, index block)들을 보호하는 distrbuted lock이다. PCM lock은 트랜잭션에 대한 어떠한 row에 대해서도 lock을 걸지 않는다.
[Lock] Oracle의 Lock에 관하여(3)...
Data Locks
Data lock(DML lock)의 목적은 여러 user에 의해 동시에 access되는 data의 integrity를 보장하는 것이다. Data locks은 동시에 충돌하는 DML 과/또는 DDL operation의 파괴적인 간섭을 방지한다.
DML operation은 서로 다른 두 level에 대해 data lock을 걸 수 있다: 특정 row들에 대해서 그리고 전체 table들에 대해서
Row Locks(TX)
Transaction은 다음 문장 중 하나에 의해서 변경되는 각각의 개별적인 row에 대해 exclusive data lock을 건다: INSERT, UPDATE, DELETE, 그리고 SELECT ... FOR UPDATE
수정된 row는 lock이 걸린 transaction이 commit되거나 rollback될 때까지 다른 user가 해당 row 를 변경할 수 없도록 항상 exclusive하게 lock을 건다. Row locks은 위에 나열된 문장의 결과처럼 Oracle에 의해서 자동으로 항상 lock을 건다.
Rows Locks and Table Locks 만약 transaction이 하나의 row에 대해서 row lock을 걸면, 그 transaction은 또한 해당 table에 대해서 table lock도 걸 수 있다. 또한 table lock은 현재의 transaction으로 data를 변경하는 것을 무시하는 DDL operation과의 충돌을 방지하기 위하여 걸려야 만 한다.
Table Locks(TM)
하나의 transaction은 다음의 DML 문장에 의해서 table이 변경될 때에 table lock을 건다: INSERT, UPDATE, DELETE, SELECT ... FOR UPDATE, 그리고 LOCK TABLE. 이러한 DML operation들은 두 가지 목적으로 table lock을 요구한다: transaction에 대해 DML access를 유지하기 위해서 그리고 그 transaction과 충돌하는 DDL operation을 방지하기 위해서 어떠한 table lock도 동일한 table에 대해 exclusive DDL lock의 획득을 막음으로써 그러한 lock을 요구하는 DDL operation을 수행할 수 없게 한다.
Table lock은 몇 가지 모드로 걸릴 수가 있다: row share(RS), row exclusive(RX), share lock (S), share row exclusive(SRX), 그리고 exclusive(X). Table lock mode의 restriveness가 다른 transaction이 동일한 table에 걸린 또 다른 table lock들이 걸릴 수 있고 유지될 수 있는 lock mode들을 결정한다.
[Lock] Oracle의 Lock에 관하여(4)...
다음에 각각의 table lock에 대해 가장 덜 제한적인 것부터 가장 제한적인 것 순서대로 설명한다.
Row Share Table Locks(RS) Row share table lock(내부적으로 sub-share table lock, SS라고 불리기도 함)은 table에 lock을 걸려는 transaction이 table안에 lock된 row가 있고 그 row를 변경시키고자 하는 것을 가리킨다. Row share table lock은 다음 문장에 의해 table에 대해 자동으로 lock을 건다:
SELECT . . . FROM table . . . FOR UPDATE OF . . . ;
LOCK TABLE table IN ROW SHARE MODE;
Row share table lock은 하나의 table에 대해서 높은 concurrency의 degree를 제공하기 위한 table lock의 가장 낮은 수준의 restrictive mode이다.
Permitted Operations : Transaction에 의해서 걸리는 row share table lock은 동시에 동일한 table에 대한 query, insert, delete, update, lock row를 허용한다. 그러므로, 다른 transaction은 동일한 table에 대해 동시에 row share, row exclusive, share, 그리고 share row exclusive table lock을 걸 수가 있다.
Prohibited Operations : Transaction에 의해서 걸리는 row share table lock은 다른 transaction이 다음의 문장을 이용하여 동일한 table에 대해 exclusive write access를 수행하는 것을 방지한다:
LOCK TABLE table IN EXCLUSIVE MODE
Row Exclusive Table Locks(RX) Row exclusive table lock(내부적으로 sub-exclusive table lock, SX라 불리기도 함)은 그 lock이 걸린transaction이 그 table에 있는 row들에 대해 하나 이상의 update를 수행하고자 하는 것을 가리킨다. 다음 문장에 의해서 row exclusive table lock이 수정된 table에 대해서 자동으로 걸린다:
INSERT INTO table . . . ;
UPDATE table . . . ;
DELETE FROM table . . . ;
LOCK TABLE table IN ROW EXCLUSIVE MODE;
Row exclusive table lock은 row share table lock보다 약간 더 제한적이다.
Permitted Operations : Transaction에 의해서 거리는 row exclusive table lock은 동시에 동일한 table에 대해서 다른 transaction들이 row들을 query, insert, delete, update, lock 하는 것을 허용한다. 그러므로, row exclusive table lock들은 여러 transaction이 동일한 table에 대해 동시에 row exclusive, row share table lock을 거는 것을 허용한다.
Prohibited Operations : Transaction에 의해서 걸리는 row exclusive table lock은 다른 transaction들이 exclusive하게 읽고 쓰기 위해서 수동으로 table을 lock하는 것을 방지한다. 그러므로, 다음 문장을 사용하여 다른 transaction들은 동시에 그 table을 lock할 수 없다:
LOCK TABLE table IN SHARE MODE;
LOCK TABLE table IN SHARE EXCLUSIVE MODE;
LOCK TABLE table IN EXCLUSIVE MODE;
Share Table Locks(S) Share table lock은 다음 문장에서 지정된 table에 대해서 자동으로 lock을 건다.
LOCK TABLE table IN SHARE MODE;
Permitted Operations : Transaction에 의해서 걸리는 share table lock은 다른 transaction들이 단지, table에 대한 query, SELECT ... FOR UPDATE를 이용한 특정 row에 대한 lock, LOCK TABLE ... IN SHARE MODE문들을 성공적으로 수행하기 위해서 허용한다; 다른 transaction에 의한 갱신은 허용하지 않는다. 여러 transaction이 동일한 table에 대해 동시에 share table lock을 수행할 수 있다. 이 경우에 어떠한 transaction도 table을 update할 수 없다. (Transaction이 SELECT ... FOR UPDATE문장의 결과로써 row lock들을 유지할 지라도). 그러므로 만약 다른 transaction이 동일한 table에 대해 share table lock을 또한 가지지 않을 때에만 share table lock을 가지는 transaction이 update 할 수 있다.
Prohibited Operations : Transaction에 의해서 걸리는 Share table lock은 다른 transaction이 다음 문장으로 동일한 table을 변경하는 것을 방지한다:
LOCK TABLE table IN SHARE ROW EXCLUSIVE MODE;
LOCK TABLE table IN EXCLUSIVE MODE;
LOCK TABLE table IN ROW EXCLUSIVE MODE;
Share Row Exclusive Table Locks(SRX) Share row exclusive table lock(내부적으로 share-sub-exclusive table lock, SSX라고 불리기도 함)은 share table lock보다 좀 더 제한적이다. Share row exclusive table lock은 다음처럼 하나의 table에 대해서 걸린다.
[Lock] Oracle의 Lock에 관하여(5)...
LOCK TABLE table IN SHARE ROW EXCLUSIVE MODE;
Permitted Operations : 한 시점에 주어진 table에 대해 하나의 share row exclusive table lock만이 걸릴 수 있다. transaction에 의해 걸린 share row exclusive table lock은 다른 transaction이 query을 하거나 SELECT ... FOR UPDATE로 특정 row를 lock하는 것을 허용하나 table의 갱신은 허용하지 않는다.
Prohibited Operations : Transaction에 의해서 걸리는 share row exclusive table lock은 다른 transaction이 동일한 table에 대해 row exclusive table lock을 걸어 table을 변경하는 것을 허용하지 않는다. Share row exclusive table lock은 다른 transaction이 다음 문장을 이용하여 share, share row exclusive, exclusive table lock 을 수행하는 것을 방지한다.
LOCK TABLE table IN SHARE MODE;
LOCK TABLE table IN SHARE ROW EXCLUSIVE MODE;
LOCK TABLE table IN ROW EXCLUSIVE MODE;
LOCK TABLE table IN EXCLUSIVE MODE;
Exclusive Table Locks(X) Exclusive table lock은 lock을 건 transaction이 table에 대한 access를 exclusive write로 허용하는table lock의 가장 제한적인 모드이다. Exclusive table lock은 다음 문w장에 의해 걸린다:
LOCK TABLE table IN EXCLUSIVE MODE;
Permitted Operations : 오직 하나의 transaction이 table에 대해 exclusive table lock을 걸 수 있다.
Prohibited Operations : Exclusive table lock은 다른 transaction이 그 table을 query하는 것만 허용한다. Exclusive table lock은 어떤 종류의 DML문이나 어떤 종류의 lock도 금지한다.
DEFAULT LOCKING FOR INSERT, UPDATE, DELETE AND SELECT ... FOR UPDATE STATEMENT INSERT, UPDATE, DELETE,
그리고 SELECT ... FOR UPDATE 문장의 특성은 다음과 같다.
DML문장을 포함하는 transaction은 문장에 의해서 변경되는 row들에 대해 exclusive row lock을 건다.그러므로 locking transaction이 commit되거나 rollback될 때까지 다른 transaction이 lock된 row를 삭제하거나 변경할 수 없다.
DML문장을 포함하는 transaction은 subquery나 WHERE절의 query와 같은 묵시적인 query에 의해서 선택된 어떠한 row에 대하여 row lock을 걸 필요가 없다.
Transaction의 query은 동일한 transaction의 DML문장에 의한 변화는 볼 수 있지만, transaction이 시작된 이후의 다른 transaction에 의한 변화는 볼 수 없다.
요구되는 exclusive row lock이외에 추가로, DML문장을 포함하는 transaction은 영향받는 row를 포함하는 table에 대해 최소한 하나의 row exclusive table lock을 건다.
[TableSpace]TableSpace 관리(1)
TableSpace 관리
1. 다중 TableSpace관리
- Data Dictionary Data와 사용자 Data의 분리
- 서로다른 응용프로그램끼리 TableSpace의 분리
- I/O 경합을 줄이기 위해 다른 TableSpace의 DataFile을 다른 디스크에 저장
- 사용자 Data와 RollBack Segment의 분리
2. TableSpace의 생성
- RBS라는 TableSpace를 생성해보자
Create tablespace RBS
Datafile ‘/usr/oradata/rbs01.dbf’ size 50M
Default storage (
Initial 100k
Next 100k
Minextents 2
Maxextents 50
Pctincrease 0)
Offline;
이름이 RBS이며 초기영역은 50M이고 실제파일은 rbs01.dbf라는 이름으로
생기게 된다. 파일의 경로를 지정하지 않으면 서버의 현재 디렉토리에 생성된다. 또한 Object가 처음 만들어 질 때 최초 확장영역은 2개가되며, 50개의 확장영역이 Max라는 의미임 Default Storage의 경우 만약 create table명령으로 Table을 만들때 storage구를 주지 않았다고 했을때는 의에서 정한 해당 TableSpace의 default storage구에 있는 설정 값을 이용하게 된다. 웬만하면 주는게 낫죠.
3. 임시 TableSpace의 생성
- 다중 정렬작업의 동시 수행을 개선하거나 오버헤드등을 감소하고자
할 때 임시 TableSpace를 생성한다.
- 임시 TableSpace에는 영구적인 개체를 저장할수 없다.
- 임시 TableSpace의 저장영역 할당 및 해제에 관한 사항은
v$sort_segment를 통해 확인할수 있다
- 생성:create tablespace tmp temporary;
- 기존 TableSpace를 임시 TableSpace로 변경 :
alter tablespace myTS temporary;
4. TableSpace의 Storage Parameter 변경
- alter tablespace RBS
default storage (
initial 10k
next 50k
minextents 3
maxextents 121
pctincrease 50);
5. 빈영역의 통합
- TableSpace의 Segment에 관한 영역은 확장영역으로 관리하며 확장영역은 특정수의 연속적인 Data Block으로 이루어져 있다., TableSpace의
Segment에 새 확장영역을 할당하는 경우 필요한 확장영역 크기에 가장
근사한 빈 확장영역을 사용한다, 따라서 커다란 빈확장영역이 단편화
되거나 작은 연속적인 빈 확장영역이 하나의 큰확장영역으로 병합된다.
그러나 빈 영역의 연속적인 할당 및 할당해제는 TableSpace를 단편화하며
큰 확장영역을 훨씬 어렵게 할당도록 만든다. 기본적으로 SMON(시스템모니터) 프로세스는 백그라운드에서 TableSpace의 빈확장영역을 계속병합한다.
원한다면 SMON의 병합기능을 사용하지 않을수도 있다. 영역의 단편화가 심하면 빈 영역을 단일영역 Transaction으로 병합할수 있다. 아래의 명령을 사용하여 모든 사용가능한 빈 확장영역을 더큰 연속적 확장영역으로 병합할수 있다.
Alter tablespace users coalesce;
또한 이명령을 사용하면 SMON의 확장영역 할당 병합을 보조함으로서 영역할당 성능을 향상 시킬수 있다. 이명령을 실행하더라도 동일한 TableSpace에 엑세스하는 다른 사용자는 영향을 받지않는다.
- TableSpace에서 병합가능한 확장영역에 대한 통계를 나타내려면
DBA_FREE_SPACE_COALESCED View를 질의해보면 된다.
View의 각 항목은 아래와 같다.
----------------------------------------------------------------------------------
Column Name Null? Type
------------------------------ -------- ----------------------------------------------------
TABLESPACE_NAME NOT NULL VARCHAR2(30)
TOTAL_EXTENTS NUMBER
EXTENTS_COALESCED NUMBER
PERCENT_EXTENTS_COALESCED NUMBER
TOTAL_BYTES NUMBER
BYTES_COALESCED NUMBER
TOTAL_BLOCKS NUMBER
BLOCKS_COALESCED NUMBER
PERCENT_BLOCKS_COALESCED NUMBER
6. TableSpace의 가용성 변경
a. TableSpace를 온라인으로 설정
- System TableSpace는 항상 온라인이어야함(Data Dictuinary는 항상
사용해야 한다.)
- 예]Alter tablespace users online;
b. TableSpace를 오프라인으로 설정
- dataBase의 일부분만 사용할 경우
- 응용프로그램을 갱신하거나 유지하는동안 응용프로그램과 관련된 Table그룹을 일시적으로 사용못하게 할경우
a. 정상 Offline(normal)
- DataFile에 오류가 없다면 정상적으로 Offline이 가능하다.
- 쓰기 오류가 발생하면 TableSpace의 모든 DataFile에 대해 Offline으로 설정할수 없다.
- 정상 Offline 우선순위에서 Oracle7은 TableSapce가 Offline으로 설정될때 모든 DataFile에 대해 체크포인트를 수행한다.
예)alter tablespace users offline normal
b. 임시 Offline(temporary)
- TableSpace내의 하나이상의 DataFile에 오류가 있어도 TableSapce를 일시적으로 Offline 시킬수 있다. 임시 Offline 우선순위에서 Oracle7은 아직 Offline이 아닌 DataFile을 Offline으로 설정하여 체크포인터를 수행한다.
임시 Option을 사용하더라도 Offline File이 없는경우 TableSpace를 온라인으로 설정시 매체복구를 수행안해도 된다. 그러나 쓰기오류가 인해 하나이상의 DataFile이 Offline이고 일시적으로 TableSpace를 Offline 시킬하려면 TableSpace를 Online으로 설정하기전에 복구해야 한다.
예) alter tablespace users temporary
c. 즉시 Offline(immediate)
- Oracle이 DataFile에 대해 체크포인트를 수행하지 않아도 TableSpace를 즉시 Offline 시킬수 있다, 즉시 Offline 우선순위에서 TableSpace를 Online으로 설정하기전 매체복구를 수행해야 한다. DataBase가 NoArchive Mode로 운용중이라면 즉시 Offline은 불가능하다.
예)alter tablespace users offline immediate
7. TableSpace를 읽기전용으로 만들기
- TableSpace를 일기 전용으로 만들면 쓰기작업을 방지할수 있다. 읽기전용으로 만든후에 백업본을 받아 두어야 한다. Alter tablespace로 읽기전용으로 만든다.
Alter tablespace users read only;
TableSpace를 읽기전용으로 만든후 관련파일을 읽기전용 매체에 복사할수 있다. 그런후 새위치를 지정하려면 SQL명령어 alter database rename~을 사용하여 제어파일의 DataFile이름을 변경해야 한다.
- 각 Table에 수행되는 select count(*)~같은 간단한 질의는 TableSpace내의 Data Block에 가장 효율적으로 계속 엑세스 할수 있도록 한다. 이렇게 되면 Oracle이 가장 최근에 블록을 수정한 트랜잭션 상태를 검사하지 않아도 된다.
a.필요조건
- TableSpace는 Online 이어야 한다.
- TableSapce내에 활성 Transaction이 없어야 한다.
- TableSpace에 사용중인 RollBack Segment가 없어야 한다.
(System TableSpace는 읽기전용으로 만들수 없다.)
- TableSpace는 현재 Online BackUp을 수행하고 있지 않아야 한다.
- COMPATIBLE 초기화 매개변수는 7.1.0 이상의 값으로 설정되어야 한다.
8. TableSpace를 Write가능하도록 만들기
Alter tablespace users read write;
- TableSpace내의 모든 DataFile은 Online 이어야하며
9. TableSpace의 삭제
- TableSpace를 삭제하면 Data의 복구는 불가능하다.
- 전후로 DB를 백업하는게 좋다.
- TableSapce를 삭제하면 DataBase 제어파일에 있는 파일 Pointer 만 삭제된다. 그러므로 DataFile은 계속 존재한다. OS명령으로 파일을 지우면 된다.
- TableSpace내에 사용중인 Segment가 있다면 삭제불가.
예를들면 TableSpace내의 Table이 현재 사용중이거나 TableSpace에 사용중인 롤백시그먼트가 있다면 삭제할수 없다. 즉 Drop시키기전에 Offline 시켜야한다.
- TableSpace를 삭제후 TableSpace의 입력항목은 Data Dictionary에 남아 있으나 TableSpace는 Invalid 상태가 된다.(dba_tablespaces View확인)
- drop tablespace users including contents;
- TableSpace가 비어 있다면 including contents를 사용안해도 된다.
- TableSpace내의 Object가 다른 TableSpace의 Table에 있는 외래키로 언급되는 기본키나 고유키를 가지는 Table을 포함하거나, 자식 Table의 foreign key 제약조건을 삭제하고져 할때는 cascade constraints 옵션을 이용하면 된다.
|
