search
Docs Home

데이터 정의어

DDL를 자세히 설명합니다. 다수의 DDL 명령어가 공통으로 포함하는 문법 요소를 설명하고, 그다음 각 명령어를 설명합니다.

DDL 명령어는 알파벳 순으로 나열하고, 각 명령어에 대한 설명과 문법, 예제를 기술합니다. 문법을 설명할 때는 [그림 1]의 형식을 그대로 따르고, 키워드와 문법의 구성요소는 별도의 표로 설명합니다.

hashtag
DDL공통 문법 요소

hashtag
제약조건

테이블 또는 뷰에 포함되는 데이터의 무결성을 위해 제한 사항을 설정할 수 있는데, 이를 제약조건이라고 합니다. 제약조건의 이름은 생략할 수 있습니다. 생략하는 경우 시스템에서 유일한 이름으로 자동 생성됩니다. 제 약조건에는 NOT NULL, UNIQUE, PRIMARY KEY, FOREIGN KEY, CHECK가 있습니다.

각각의 제약조건을 구성하는 문법은 다음과 같습니다.

hashtag
NOT NULL

NOT NULL 제약조건은 해당 컬럼의 값으로 NULL을 허용하지 않고, 반드시 데이터를 입력해야 합니다. 이 와는 반대로 제약조건이 NULL이면 해당 컬럼은 NULL 값을 허용합니다. 컬럼에 명시적으로 NULL이나 NOT NULL을 설정하지 않았다면 NULL이 컬럼의 디폴트로 설정됩니다.

hashtag
UNIQUE

UNIQUE 제약조건은 해당 컬럼이 중복되는 데이터가 존재할 수 없는 유일성을 보장하는 제약조건입니다. 한 로우(ROW)의 해당 컬럼의 조합(Combination) 값이 다른 로우(ROW)의 같은 컬럼의 조합 값으로 사용 될 수 없습니다. 다시 말해 동시에 2개 이상의 로우(ROW)에서 동일한 컬럼의 조합 값을 갖는 것을 제한합니다.

UNIQUE 제약조건은 해당 제약조건에 설정된 컬럼 값으로 NULL 값을 갖는 것을 허용합니다. 만약 하나의 컬럼만을 갖는 UNIQUE 제약조건이라면 여러 개의 로우에서 해당 컬럼에 NULL 값을 가질 수 있습니다.

그러나 여러 개의 컬럼을 포함하는 UNIQUE 제약조건이라면 제약조건에 포함되는 컬럼 전부가 NULL인 경우를 제외하고, 컬럼의 일부가 NULL이면서 컬럼의 조합 값이 동일한 경우를 허용하지 않습니다.

다음은 UNIQUE 제약조건을 설명하는 예입니다.

위와 같이 제약조건이 컬럼 a, b에 설정되어 있습니다면 해당 컬럼들에 (1, NULL), (NULL, 2) 같은 값을 가진 로우(ROW)들은 허용이 됩니다. 하지만, 두 개 이상의 (1, NULL)은 허용하지 않습니다. 그러나 모든 컬럼의 조 합이 NULL인 경우 (NULL, NULL)와 같은 값을 가진 로우(ROW)들은 여러 개를 가질 수 있습니다.

hashtag
PRIMARY KEY

PRIMARY KEY 제약조건은 NOT NULL 제약조건과 UNIQUE 제약조건의 결합과 같습니다. 테이블이나 뷰는 단 한 개의 PRIMARY KEY 제약조건을 가질 수 있습니다.

Tibero는 UNIQUE 제약조건이나 PRIMARY KEY 제약조건이 설정된 컬럼에 유일 인덱스(Unique Index) 를 생성합니다. 만약 constraint_state에서 인덱스를 설정하지 않습니다면 자동으로 UNIQUE 인덱스를 생성하 거나, 이미 존재하는 UNIQUE 인덱스를 사용합니다.

hashtag
FOREIGN KEY

FOREIGN KEY 제약조건은 같은 테이블 또는 서로 다른 두 개 테이블들의 키 컬럼 사이의 관계입니다. 즉, 어떤 컬럼의 REFERENCED KEY와 FOREIGN KEY 사이의 관계입니다. FOREIGN KEY로 지정된 컬럼의 값은 FOREIGN KEY가 참조하는 컬럼의 데이터 값만을 가질 수 있습니다. 복합(Composite) 컬럼으로 구성된 FOREIGN KEY도 마찬가지입니다.

FOREIGN KEY로 지정된 컬럼과 REFERENCED KEY로 지정된 컬럼은 개수와 각각의 데이터 타입이 같 아야 합니다.

다음은 FOREIGN KEY 제약조건을 설명하는 예입니다.

위와 같이 REFERENCED KEY로 지정된 컬럼의 값이 (1,2), (2,3), (4,2)가 존재합니다면, FOREIGN KEY로 지정된 컬럼의 값도 (1,2), (2,3), (4,2)만 가능합니다. 다른 값은 허용되지 않습니다. 다른 테이블의 컬럼을 참조 하는 경우에는 해당 테이블에 대한 REFERENCE OBJECT 특권이 필요합니다.

하나의 컬럼은 여러 개의 FOREIGN KEY 제약조건에 참여할 수 있습니다. REFERENCED KEY는 이미 UNIQUE 또는 PRIMARY KEY로 지정된 컬럼이어야만 합니다.

REFERENCED KEY는 같은 테이블의 컬럼이 될 수도 있고 다른 테이블의 컬럼이 될 수도 있습니다. 같은 테 이블의 컬럼을 참조하는 경우 테이블 이름은 생략할 수 있습니다. REFERENCED KEY의 PRIMARY KEY 값 과 UNIQUE 값을 삭제하면 참조 무결성을 해칠 수 있기 때문에 이를 보장하기 위해 FOREIGN KEY도 같 이 처리를 해주어야만 합니다.

Tibero는 FOREIGN KEY 제약조건이 지정된 컬럼에 인덱스를 생성하지 않습니다.

FOREIGN KEY를 지정할 때 설정할 수 있는 옵션은 다음과 같습니다.

옵션
설명

ON DELETE

references_clause의 ON DELETE 옵션을 이용하여 참조된 컬럼 값이 삭제될 때 참조하는 컬럼 값에 대한 동작을 설정할 수 있음

CASCADE

참조되는 컬럼 값이 삭제될 때 참조하는 컬럼 값도 같이 삭제

SET NULL

외참조되는 컬럼 값이 삭제될 때 참조하는 컬럼 값을 NULL로 변경

hashtag
CHECK

CHECK 제약조건은 expr로 표현한 조건이 항상 참이 되도록 유지합니다. 테이블에 DML이 있을 때마다 조 건을 평가한 후 그 조건을 만족하지 못하면 에러를 발생합니다.

inline_constraint의 CHECK 제약조건인 경우는 해당 컬럼의 한 개만 조건의 수식에 포함할 수 있고, out ofline_constraint의 CHECK 제약조건인 경우는 제약조건이 선언된 테이블의 모든 컬럼이 나올 수 있습니다. 다른 테이블의 컬럼은 조건의 수식에 포함할 수 없습니다.

circle-info

참고

UNIQUE, PRIMARY KEY, FOREIGN KEY가 포함할 수 있는 컬럼 수는 최대 32개입니다. UNIQUE, PRIMARY KEY 제약조건은 구성되는 컬럼으로 인덱스를 사용하기 때문에 컬럼 전체의 길이가 인덱 스를 생성할 수 있는 최대 길이를 넘을 수 없습니다. 같은 컬럼으로 구성된 UNIQUE와 PRIMARY KEY를 동시에 설정할 수 없습니다.

LONG, LONG RAW는 UNIQUE, PRIMARY KEY, FOREIGN KEY 제약조건의 키 컬럼에 포함될 수 없습니다.

hashtag
Constraint_state

Constraint_state는 제약조건을 활성화하거나 비활성화하고 이미 삽입된 데이터가 제약조건을 만족하는 지 검증하는 역할을 합니다. Constraint_state는 테이블이 처음 생성될 때나 컬럼이 새로 추가될 때처럼 제약 조건이 생성되기 전에 사용할 수 있습니다. 또한, Constraint_state는 테이블이 생성되고 나서도 제약조건을 추 가로 설정할 때 사용할 수 있습니다.

Constraint_state의 세부 내용은 다음과 같습니다.

  • 문법

  • 구성요소

– constraint_state

구성요소
설명

ENABLE

  • 새로 삽입될 데이터에 제약조건을 적용

  • 처음 제약조건이 생성될 때 ENABLE이나 DISABLE을 지정하지 않으면 ENABLE이 디폴트로 설정

  • DISABLE 상태에서 적용되지 않은 제약조건에 ENABLE을 적용합니다면, 앞으로 삽입될 데이터에 제약조건을 다시 적용시킬 수 있음

  • 만약 UNIQUE나 PRIMARY KEY 제약조건에 ENABLE이 적용되면, 이미 존 재하는 UNIQUE 인덱스를 사용

  • 만약 UNIQUE 인덱스가 존재하지 않는 상태라면 새로 UNIQUE 인덱스를 생성

  • FOREIGN KEY 제약조건의 경우 비유일 인덱스에 대해 같은 동작을 함

DISABLE

  • 새로 삽입될 데이터에 제약조건을 적용하지 않음

  • 만약 UNIQUE나 PRIMARY KEY 제약조건, FOREIGN KEY 제약조건을 DISABLE로 설정하면, 관련 인덱스를 삭제

  • DISABLE로 설정된 UNIQUE나 PRIMARY KEY를 참조하는 FOREIGN KEY는 ENABLE로 설정할 수 없음

  • 만약 제약조건을 생성할 때 같이 만들어진 인덱스가 아닌, 제약조건이 생성되면서 원래 존재하던 인덱스를 사용할 경우에는 인덱스가 삭제되지는 않음

VALIDATE

  • 이미 테이블에 삽입된 데이터가 제약조건을 만족하는지 체크하고 보장

  • 만약 VALIDATE로 설정했지만, 데이터가 이 제약조건을 만족하지 못하는 경우에는 에러를 반환하고 VALIDATE가 들어간 DDL 문장은 실행 실패

  • DISABLE VALIDATE 상태로 만든다면, 이미 삽입된 데이터에 대한 제약조건에 대한 완전성을 보장하면서 앞으로 삽입될 데이터에 대해서는 보장하지 않는다는 의미가 되기 때문에 이 상태의 제약조건이 존재하는 테이블에서는 데이터의 삽입, 삭제, 갱신을 할 수 없게 됨

NOVALIDATE

이미 테이블에 삽입된 데이터에 대해 제약조건을 만족하는지 검사하지 않음

using_index_clause

  • UNIQUE나 PRIMARY KEY를 설정할 때 사용할 인덱스를 지정하거나 생성하여 사용할 수 있음

  • schema.index_name을 사용하여 이미 존재하는 인덱스를 사용할 수도 있고, create_index를 사용하여 인덱스를 생성하여 사용할 수도 있음

  • create_index와 index_attributes는 “CREATE INDEX”를 참고

– using_index_clause

구성요소
설명

schema

  • 사용할 인덱스가 속해 있는 스키마를 명시

  • 생략할 경우 현재 사용자의 스키마로 인식됨

index_name

사용할 인덱스의 이름을 명시

create_index

  • 인덱스를 새로 생성하여 사용하려고 할 때 명시

  • 자세한 내용은 “CREATE INDEX”를 참고

index_attributes

  • 인덱스의 속성을 설정할 때 사용

  • 자세한 내용은 “CREATE INDEX” 를 참고

– atbl_con_alterstate_cl

구성요소
설명

ENABLE

구성요소 설명 중 constraint_state를 참고

DISABLE

구성요소 설명 중 constraint_state를 참고

VALIDATE

구성요소 설명 중 constraint_state를 참고

NOVALIDATE

구성요소 설명 중 constraint_state를 참고

PRIMARY KEY

PRIMARY KEY 제약조건을 설정

UNIQUE column_name

  • UNIQUE 제약조건을 설정

  • column_name에는 UNIQUE 제약조건을 지정할 컬럼의 이름을 명시

CONSTRAINT constraint_name

상태를 변경할 제약조건의 이름을 명시

using_index_clause

구성요소 설명 중 constraint_state를 참고

CASCADE

  • 참조된 UNIQUE나 PRIMARY KEY 제약조건을 비활성화할 때 관련된 FOREIGN KEY까지 함께 비활성화를 하기 위해 사용

  • FOREIGN KEY가 존재하는 제약조건을 비활성화하는 경우에는 반드시 포함되어야 함

KEEP INDEX

  • 제약조건을 비활성화하면서 제약조건에서 사용한 인덱스를 제거하지 않고 그냥 유지하고자 할 때 명시

  • 기본값이므로 생략할 수 있음

DROP INDEX

제약조건을 제거하고 할 때 그 제약조건에서 사용한 인덱스도 함께 제거하고자 할 때 명시

hashtag
Deferrable_option

제약 조건을 매 DML의 경우 체크하는 것이 아니라, 커밋 시점에 마지막 커밋된 시점 이후에 DML이 된 데 이터에 대하여 제약 조건을 확인하도록 하는 기능입니다. 커밋 시점에 수행하는 제약 조건을 통과 하지 못했 을 경우 마지막 커밋 시점으로 데이터가 전부 rollback됩니다. FOREIGN KEY를 제외한 제약 조건에서 사용 가능합니다.

Deferrable_option의 세부 내용은 다음과 같습니다.

  • 문법

  • 구성요소

– deferrable_option

구성요소
설명

DEFERABLE (INITIALLY (IMMEDIATE))

  • Deferrable constraint 기능을 사용하는 제약 조건 생성문

  • Deferrable constraint 기능은 사용하지만, 일반 제약조건과 마찬가지로 DML의 경우에 매번 바로바로 조건을 체크할 경우에 사용됨

  • INITIALLY 또는 IMMEDIATE가 생략되어도 의미는 같음

DEFERABLE INITIALLY DEFERRED

Deferrable constraint 기능을 사용하며, 제약 조건을 commit 시점에만 체크하도록 할 경우에 사용됨

INITIALLY DEFERRED DEFERRABLE

Deferrable constraint 기능을 사용하며, 제약 조건을 commit 시점에만 체크하도록 할 경우에 사용됨

hashtag
Sgmt_attr

저장 공간의 물리적인 성질과 테이블 스페이스 등을 지정하기 위한 문장입니다.

Sgmt_attr의 세부 내용은 다음과 같습니다.

  • 문법

  • 구성요소

구성요소
설명

TABLESPACE tablespace_name

  • 데이터가 저장되는 테이블 스페이스를 지정할 수 있음

  • 지정하지 않으면 사용자의 디폴트 테이블 스페이스를 사용하게 됨

  • 임시 테이블의 경우 디폴트로 지정된 임시 테이블 스페이스를 사용

  • tablespace_name에 테이블 스페이스의 이름을 명시

PCTFREE unsigned_integer

  • 데이터를 디스크 블록에 저장할 때 데이터가 변경되어 크기가 증가할 것에 대비하여 얼마만큼의 영역을 예비로 남겨둘지를 설정하는 값

  • 1 ~ 99 사이의 값을 설정할 수 있으며, 지정하지 않으면 기본값은 10

  • unsigned_integer에 해당 값을 명시

INITRANS unsigned_integer

  • 디스크 블록마다 트랜잭션 엔트리(Transaction Entry)를 위한 공간을 몇 개를 확보할 것인가를 나타

  • 트랜잭션 엔트리는 블록에 공간이 남아있다면 필요할 때 확장

  • 따라서 미리 큰 값을 설정할 필요는 없음

  • 최솟값은 1이며, 최댓값은 디스크 블록의 크기에 따라 다름

  • 지정하지 않으면 기본값은 2

  • unsigned_integer에 해당 값을 명시

LOGGING / NOLOGGING

  • Direct-Path Loading을 이용하는 경우 Redo 로그를 남기지 않음

  • 단, Archive Mode를 사용할 경우에는 로그를 남김

  • 지정하지 않으면 기본값은 LOGGING

  • 현재 파티션 테이블별로 LOGGING 옵션을 설정하는 것은 지원하지 않음

storage_clause

  • 세그먼트의 세부적인 속성을 정의

  • 자세한 내용은 “Storage_clause”를 참고

hashtag
Storage_clause

세그먼트의 세부적인 속성을 정의하기 위한 문장입니다.

Storage_clause의 세부 내용은 다음과 같습니다.

  • 문법

  • 구성요소

구성요소
설명

MAXEXTENTS

  • 세그먼트에 할당되는 최대 익스텐트의 개수를 지정

  • ALTER TABLE 문에서는 예외적으로 MAXEXTENTS 값 조정이 불가능합니다.

unsigned_integer

제한할 익스텐트의 개수를 명시

UNLIMITED

  • 익스텐트의 개수를 제한하지 않음

  • 지정하지 않으면, 기본값은 UNLIMITED

BUFFER_POOL

해당 세그먼트의 데이터 블록을 어떤 Buffer Pool에 넣을 것인지를 지정

KEEP

  • 세그먼트의 블록을 KEEP Buffer Pool에 넣어 메모리에 보존하도록 함

  • 이로써 I/O 연산을 하는 시간을 줄일 수 있음

  • $TB_SID.tip 파일에 DB_KEEP_CACHE_SIZE 파라미터가 설정되어 있어야 Buffer 캐시에 KEEP Buffer Pool이 설정됨

  • DB_KEEP_CACHE_SIZE 파라미터가 설정되어 있지 않으면 BUFFER_POOL KEEP 지정은 의미가 없음

RECYCLE

  • 세그먼트의 블록을 RECYCLE Buffer Pool에 넣어 DEFAULT Buffer Pool이 불필요한 버퍼 캐시를 저장하지 않도록 함

  • $TB_SID.tip 파일에 DB_RECYCLE_CACHE_SIZE 파라미터가 설정되어 있어야 Buffer 캐시에 RECYCLE Buffer Pool이 설정됨

  • DB_RECYCLE_CACHE_SIZE 파라미터가 설정되어 있지 않으면 BUFFER_POOL RECYCLE 지정은 의미가 없음

DEFAULT

DEFAULT로 지정하거나 BUFFER_POOL 옵션을 지정하지 않으면, DEFAULT Buffer Pool을 사용

hashtag
ALTER DATABASE

데이터베이스의 상태나 구성파일을 변경합니다. 또한 데이터베이스를 복구하는 데에도 사용됩니다.

ALTER DATABASE의 세부 내용은 다음과 같습니다.

  • 문법

BA 특권이 있어야 ALTER DATABASE를 실행할 수 있습니다.

  • 구성요소

– alter_database

구성요소
설명

database_name

  • 변경할 데이터베이스를 명시

  • database_name은 생략할 수 있음

  • $TB_SID.tip 파일에 설정된 DB_NAME 파라미터의 값과 같아야 함

startup_clauses

  • startup_clauses는 데이터베이스를 정상적으로 사용할 수 있도록 기동할 때 사용하는 절

  • MOUNT 모드에서만 사용할 수 있음

recovery_clauses

  • recovery_clauses는 미디어 복구(Media Recovery)를 위해 사용하는 절

  • MOUNT 모드에서만 사용할 수 있음

dbfile_clauses

  • dbfile_clauses는 데이터 파일의 추가, 재생성 등의 작업을 하기 위해 사용하는 절

  • 파일을 복구하는 문장과 데이터 파일이나 임시 파일의 속성을 수정하는 문장으로 나뉨

  • 파일의 지정은 파일의 전체 경로나 파일 번호를 명시하여 지정할 수 있음

  • 데이터 파일과 임시파일의 파일 번호는 다음의 뷰를 통해 알 수 있음 – V$DATAFILE – V$TEMPFILE – V$RECOVER_FILE – DBA_DATA_FILES – DBA_TEMP_FILES

logfile_clauses

  • logfile_clauses는 ARCHIVELOG 모드를 설정하거나 로그 파일을 추가, 제거하기 위한 절

  • MOUNT 모드에서만 사용할 수 있음

control_file_clauses

  • control_file_clauses는 컨트롤 파일을 물리적으로 복사하여 명시한 파일로 백업 본을 만들기 위한 절과 컨트롤 파일을 새로 생성하는 문장을 명시한 파일에 저장하기 위한 절로 나뉨

  • 후자의 경우에는 다음과 같은 옵션을 함께 사용할 수 있음

  • 컨트롤 파일이 이미 존재하는 경우 REUSE 옵션을 사용할 수 있음

  • 컨트롤 파일을 생성하는 문장은 RESETLOGS를 사용할 경우가 그렇지 않은 경우로 나눌 수 있음

default_setting_clauses

  • default_setting_clauses는 데이터베이스의 디폴트 테이블 스페이스를 변경하기 위한 절

  • TEMPORARY 테이블 스페이스와 일반 테이블 스페이스를 변경할 수 있음

standby_clauses

standby_clauses는 Standby 데이터베이스와 관련된 작업을 할 수 있음

flashback_database_clauses

플래시백 데이터베이스와 관련된 작업을 할 수 있음

begin_backup_clause

  • 백업이 오랫동안 수행될 경우를 시작할 때 사용

  • 백업 대상 테이블 스페이스들을 별도로 지정하지 않은 경우에는 데이터베이스 전체에 대해 실행됨

end_backup_clause

데이터베이스 백업을 끝낼 때 사용됨

– startup_clauses

구성요소
설명

READ WRITE

  • 데이터베이스를 READ WRITE 모드로 기동시킨다.사용자가 읽기와 쓰기를 모두 할 수 있고, Redo 로그를 저장

  • 기본값이므로 생략할 수 있음

READ ONLY

  • 사용자가 읽기만을 할 수 있음

  • 따라서 Redo 로그를 저장하지 못함

READ ONLY CONTINUE RECOVERY

  • Standby 데이터베이스를 읽기 전용으로 전환한 상태에서 동시에 Primary 데이터베이스로부터 전송받은 Redo 로그를 적용하는 모드로 전환

  • Standby 상태에서만 사용할 수 있음

  • 자세한 내용은 “Tibero 관리자 안내서”를 참고

READ RESETLOGS

  • 로그의 시퀀스를 1로 초기화하고, 아카이브되지 않은 로그를 아카이브

  • 남아 있는 Redo 로그 정보는 적용될 일이 없어서 삭제됨

– recovery_clauses

구성요소
설명

AUTOMATIC

  • AUTOMATIC을 사용해 복구 과정을 자동화하면, 필요한 로그 파일을 일일이 지정하지 않고 원하는 조건까지 자동 복구를 할 수 있음

  • 자동 복구를 위해서는 컨트롤 파일에 온라인 로그 파일과 아카이브 로그 파일이 제대로 명시되어 있어야 함

  • FROM 절을 통해 사용할 아카이브 로그 파일이 있는 디렉터리를 지정할 수 있음

  • FROM 절로 지정하지 않으면 LOG_ARCHIVE_DEST 파라미터에 설정된 디렉터리를 사용

full_database_recovery_clause

  • 데이터베이스 전체에 대한 미디어 복구를 시작할 때 사용하는 절

  • 완전 복구 또는 불완전 복구를 지정할 수 있음

  • full_database_recovery_clause를 생략하면 데이터베이스 전체에 대한 완전 복구를 시작

partial_database_recovery_clause

데이터베이스 전체가 아닌 특정 테이블 스페이스나 데이터 파일에 미디어 복구를 시작할 때 사용

LOGFILE

적용할 로그 파일을 지정하고, 복구를 진행할 수 있음

filename

지정할 파일의 이름을 명시

CANCEL

복구를 마칠 때 사용

FOR STANDBY

Primary의 Hot Backup으로 Standby를 구축할 때 사용

복구는 다음과 같이 3단계로 진행됩니다.

단계
명칭
설명

1

시작

복구를 시작하는 단계

2

진행

로그 파일을 사용하여 복구를 순차적으로 진행하는 단계

3

종료

복구를 종료하는 단계

복구는 다음과 같이 두 가지 종류로 구분됩니다.

구분
설명

완전 복구

종료 시점을 지정할 수 없으며, 가장 최근의 로그 파일의 내용까지 적용하여 복구 를 수행

불완전 복구

  • 종료 시점을 명시적으로 지정할 수 있음

  • 종료 시점의 지정은 TSN 값이나 시간을 사용하여 지정할 수 있음

  • 또한, CANCEL 문을 사용해 원하는 시점에서 종료를 할 수도 있음

– full_database_recovery_clause

구성요소
설명

UNTIL CANCEL

  • 불완전 복구를 할 때 사용

  • UNTIL CANCEL을 사용한 뒤에 복구할 로그 파일을 명시

UNTIL TIME

  • 특정 시간까지 불완전 복구를 진행할 때 사용

  • 명시할 시간은 날짜형 리터럴을 사용

string literal

UNTIL TIME을 사용할 때 날짜형 리터럴을 명시

UNTIL CHANGE

  • 데이터베이스의 TSN 값을 기준으로 복구를 할 때 사용

  • TSN 값은 V$LOG 뷰를 이용하여 조회할 수 있음

unsigned_integer_64

UNTIL CHANGE를 사용할 때 TSN 값을 명시

– partial_database_recovery_clause

구성요소
설명

TABLESPACE

  • 특정 테이블 스페이스만 복구할 때 사용

  • 주로 OFFLINE IMMEDIATE 로 오프라인된 테이블 스페이스를 온라인으로 전환할 때 사용

tablespace_name

미디어 복구 대상이 되는 테이블 스페이스의 이름을 명시

filename_or_filenumber

미디어 복구 대상이 되는 데이터 파일의 이름을 명시하거나 데이터 파일의 번호를 명시

block_number

복구할 데이터 파일의 블록 번호를 명시

archivelog_filename

복구에 사용할 아카이브 로그를 지정

– dbfile_clauses

구성요소
설명

CREATE

  • 데이터 파일이 없는 경우 빈 데이터 파일을 만드는 데 사용됨

  • 생성 후 미디어 복구를 통해 데이터 파일을 복구할 수 있음

  • MOUNT 모드에서만 사용할 수 있음

DATAFILE

  • 데이터 파일을 명시하는 부분

  • 파일의 이름을 명시할 수도 있고, 파일의 번호를 명시할 수도 있음

  • 여러 개의 파일을 동시에 명시할 수 있으며, 각각의 파일을 콤마(,)를 사용해 구분

filename_or_filenumber

파일의 이름 또는 파일의 번호를 명시하는 부분

OFFLINE FOR DROP

  • 데이터 파일을 복구할 수 없을 때 해당 데이터 파일이 속한 테이블 스페이스를 제거하는 조건으로 데이터베이스를 운영할 때 사용

  • MOUNT 모드에서만 사용할 수 있음

RESIZE size

  • 파일의 크기를 증가시키거나 감소 시킬 때 사용

  • size 부분에 파일의 크기를 명시

  • 파일의 크기는 (BLOCK 개수 * DB_BLOCK_SIZE)

  • 단, 파일의 크기를 줄이는 경우 현재 사용하고 있는 크기와 입력받은 크기 중 큰 값이 파일 사이즈로 지정됨

autoextend_clause

  • AUTOEXTEND 속성을 변경할 수 있

  • 음자세한 내용은 “CREATE DATABASE”를 참고

TEMPFILE

  • 임시 파일을 명시하는 부분

  • 파일의 이름을 명시할 수도 있고, 파일의 번호를 명시할 수도 있음

  • 여러 개의 파일을 동시에 명시할 수 있으며, 각각의 파일을 콤마(,)를 사용해 구분

RENAME FILE

파일의 이름을 변경할 때 사용

filename TO filename

  • TO의 앞부분에 변경할 파일의 이름을 명시하고, 그 뒷부분에 변경 뒤의 파일의 이름을 명시

  • 여러 개의 파일을 동시에 변경할 수 있으며, 여러 개의 파일을 동시에 변경할 경우 각각의 파일을 콤마(,)를 사용해 구분

– logfile_clauses

구성요소
설명

ARCHIVELOG

ARCHIVELOG 모드를 설정할 수 있음

NOARCHIVELOG

  • NOARCHIVELOG 모드를 설정할 수 있음

  • NOARCHIVELOG 모드로 운영되는 데이터베이스는 복구가 매우 제한적

ADD LOGFILE

  • 온라인 로그 파일을 추가할 수 있음

  • 로그 그룹 전체를 추가하거나 로그 그룹에 멤버를 추가할 수 있음

  • 추가할 로그 파일은 절대경로로 명시해야 함

  • 현재 로그 그룹에 대해서는 수행할 수 없음

  • MOUNT 모드에서뿐만 아니라 데이터베이스 운영 중에도 가능

log_member_clause

  • log_member_clause는 GUOUP 절을 사용해 로그 그룹의 번호를 지정하기 위한 절

  • 자세한 내용은 “CREATE DATABASE”를 참고

MEMBER

로그 그룹 내의 특정 로그 멤버 파일을 지정할 때 사용

filename

파일의 이름을 명시

logfile_descriptor

로그 그룹이나 로그 파일을 명시

DROP LOGFILE

  • 온라인 로그 파일을 제거할 수 있음

  • 로그 파일을 추가할 때처럼 제거할 때도 그룹 전체를 제거하거나 그룹의 멤버만 제거할 수 있음

  • 로그 그룹은 반드시 2개 이상 있어야 하며, 제거할 로그 파일은 절대경로로 명시해야 함

  • 현재 로그 그룹에 대해서는 수행할 수 없음

  • MOUNT 모드에서뿐만 아니라 데이터베이스 운영 중에도 가능

– logfile_descriptor

구성요소
설명

GROUP group

로그 그룹 단위로 로그 파일을 추가하거나 제거할 때 해당 로그 그룹을 명시

filename

로그 멤버 단위로 로그 파일을 추가하거나 제거할 때 해당 파일의 이름 을 명시

– control_file_clauses

구성요소
설명

BACKUP CONTROLFILE TO

컨트롤 파일의 물리적 복사본을 백업할 때 사용

BACKUP CONTROLFILE TO TRACE AS

컨트롤 파일의 생성 문장을 백업할 때 사용

filename

컨트롤 파일의 물리적 복사본 또는 생성 문장을 저장할 파일을 지정

REUSE

컨트롤 파일의 생성 문장을 백업할 때 이미 존재하는 파일을 재사용하려면 REUSE 옵션을 사용해야 함

RESETLOGS

기존의 로그 파일은 무시하고, 로그를 초기화

NORESETLOGS

기존의 유효한 로그 파일을 계속 사용

– default_setting_clauses

구성요소
설명

DEFAULT

DEFAULT 테이블 스페이스를 변경할 때 사용하는 예약어

TEMP

  • TEMPORARY 테이블 스페이스임을 지정

  • TEMPORARY 테이블 스페이스를 쓰지 않으면 일반 테이블 스페이스를 의미

TABLESPACE

테이블 스페이스의 이름을 지정할 때 사용하는 예약어

tablespace_name

테이블 스페이스의 이름을 명시

– standby_clauses

구성요소
설명

STANDBY

  • 데이터베이스를 Standby 모드로 전환

  • MOUNT, READ ONLY 모드에서만 사용할 수 있음

STANDBY CONTROLFILE

  • 초기화 파라미터 중 STANDBY_FILE_NAME_CONVERT에 지정된 경로에 따라 컨트롤 파일에 저장된 데이터베이스 파일의 경로를 변환하여 Primary 데이터베이스에서 복사한 컨트롤 파일을 Standby 데이터베이스용으로 사용할 수 있게 해줌

  • MOUNT 모드에서만 사용할 수 있음

  • 자세한 내용은 "Tibero 관리자 안내서"를 참고

– rename_clauses

구성요소
설명

RENAME TO DBNAME

  • 데이터베이스 이름을 변경

  • MOUNT 모드에서만 사용할 수 있음

– flashback_database_clauses

구성요소
설명

FLASHBACK LOGGING ON

  • 플래시백 로깅을 활성화

  • MOUNT 모드에서 FLASHBACK_LOG_BUFFER 초기화 파라미터가 설정되어있어야 수행 가능

  • 플래시백 로그는 데이터베이스 복구 또는 NORMAL 모드로 부팅하면서부터 플래시백 로그 파일에 기록됨

FLASHBACK LOGGING OFF

  • 플래시백 로깅을 비활성화

  • MOUNT 모드에서만 수행 가능

  • 플래시백 로그는 더 이상 기록되지 않음

FLASHBACK ADD MARKER

  • 플래시백 로그를 남기는 기준인 MARKER를 추가

  • MARKER의 시점 이후에 처음 변경되는 데이터 파일의 블록들은만 플래시백 로그에 기록됨

FLASHBACK CLEAR MARKER

Marker의 기록들을 모두 삭제

FLASHBACK TO TSN flashback_target_tsn

TSN 기준 원하는 시점으로 데이터베이스의 컨트롤 파일과 데이터 파일을 플래시백

FLASHBACK TO BEFORE RESETLOGS

현 데이터베이스의 Resetlogs 부팅 직전의 시점으로 데이터베이스의 컨트롤 파일과 데이터 파일을 플래시백

  • 예제

– recovery_clauses

다음은 복구를 시작하고 로그 파일을 하나씩 적용해 완전 복구를 진행하는 예입니다.

위의 예를 보면, 마지막 부분에서 CANCEL을 사용해 복구를 종료하는 것을 알 수 있습니다.

다음은 AUTOMATIC 옵션을 사용해 자동으로 완전 복구를 진행하는 예입니다.

– full_database_recovery_clause

다음은 UNTIL CANCEL을 명시하여, 불완전 복구를 진행하는 예입니다.

위의 예는 로그 파일 3개를 복구한 뒤에 CANCEL을 사용해 복구를 마치고 있습니다.

다음은 UNTIL TIME을 이용해 불완전 복구를 진행하는 예입니다.

위의 예에서는 사용자가 2006년 11월 15일 14시경 실수로 테이블을 제거하였다고 가정합니다. 사용자 가 테이블을 제거하기 이전의 데이터베이스로 되돌리기 위해서는 불완전 복구를 해야 합니다.

먼저 되돌리려는 시점 이전에 백업한 데이터 파일을 복사한 후 제거가 일어나기 전까지의 로그 파일 을 적용하여 복구를 합니다. 따라서 위의 예에서와 같이 2006년 11월 15일 13시 59분까지 자동복구를 하면 됩니다.

다음은 UNTIL CHANGE를 이용하여 데이터베이스의 TSN 값을 기준으로 복구를 진행하는 예입니다.

위의 예에서는 먼저 V$LOG를 입력하여 로그를 조회하고, '로그 그룹 2'가 시작하는 지점까지 복구를 진행하기 위해 TSN 값 '2074'를 입력하여 복구를 진행하는 것을 볼 수 있습니다. V$LOG를 사용하면 TSN 값을 조회하거나 문제가 생긴 로그를 알아낼 수 있습니다.

– dbfile_clauses

다음은 CREATE DATAFILE을 사용하는 예입니다.

위의 예는 FILE# 2번 데이터 파일이 존재하지 않을 경우 빈 파일을 만들어 복구할 수 있도록 준비합니다.

다음은 OFFLINE FOR DROP을 사용해 데이터 파일에 속한 테이블 스페이스를 제거하는 예입니다.

OFFLINE FOR DROP은 데이터 파일을 복구할 수 없을 때 해당 데이터 파일이 속한 테이블 스페이스를 제거하는 조건으로 데이터베이스를 운영할 때 사용합니다.

다음은 RESIZE를 사용해 파일의 크기를 증가시키는 예입니다.

다음은 autoextend_clause를 명시하여 AUTOEXTEND 속성을 활성화시키는 예입니다.

– logfile_clauses

다음은 데이터베이스를 ARCHIVELOG 모드로 설정하는 예입니다.

다음은 ADD LOGFILE을 사용해 온라인 로그 파일을 추가하는 예입니다.

위의 예에서는 두 온라인 로그 파일, '/database/log010.log', '/database/log011.log'을 멤버로 갖는 로 그 그룹을 추가하고 있습니다. 온라인 로그 파일을 추가할 때는 그룹 전체를 추가하거나 그룹에 로그 멤버 를 추가할 수 있으며, 로그 파일의 절대경로를 명시해야 합니다.

다음은 로그 그룹에 로그 멤버 하나를 추가하는 예입니다.

위의 예는 '로그 그룹 3'에 로그 파일을 추가하는 예입니다. V$LOG를 사용해 현재 로그 그룹을 확인할 수 있습니다. 또한 로그 전환(Log Switch)를 활용해 현재 로그 그룹을 변경할 수도 있습니다.

위의 예에서는 V$LOG를 통해 로그 그룹이 0번인 것을 알 수 있습니다. '로그 그룹 3'에 로그 멤버의 추가 가 가능합니다는 것을 알 수 있으며, '로그 그룹 3'에 로그 멤버 'log12'를 추가하고 그 결과를 보여주고 있습니다.

다음은 DROP LOGFILE을 사용해 온라인 로그 파일을 제거하는 예입니다.

위의 예에서는 '로그 그룹 3'의 로그 멤버인 'log012.log'만 제거하는 경우와 '로그 그룹 3' 전체를 제거 하는 경우를 보여주고 있습니다.

– control_file_clauses

다음은 control_file_clauses를 사용해 컨트롤 파일의 생성 문장을 백업하는 예입니다.

위의 예는 컨트롤 파일의 생성 문장을 '/backup/create_ctr.sql'이라는 파일에 저장합니다.

다음은 RESETLOGS로 지정한 상태에서 컨트롤 파일의 생성 문장을 백업하는 예입니다.

위의 예에서는 이미 생성된 파일에 REUSE 옵션을 사용해서 컨트롤 파일의 생성 문장을 백업하는 것 을 보여준다. REUSE 옵션은 이미 존재하는 파일에 컨트롤 파일의 생성 문장을 저장하려고 할 때 사 용합니다. 만약 RESETLOGS를 지정하지 않으면, NORESETLOGS로 간주됩니다.

hashtag
ALTER DISKSPACE

디스크스페이스와 디스크스페이스에 속한 디스크의 속성과 상태를 변경합니다.

ALTER DISKSPACE의 세부 내용은 다음과 같습니다.

  • 문법

  • 구성요소

– create_diskspace

구성요소
설명

diskspace_name

변경할 디스크스페이스의 이름을 명시

add_disk_clause

  • 디스크스페이스에 디스크 추가를 선언할 때 사용

  • 리밸런스를 수행하기 전까지 디스크가 사용되지 않음

drop_disk_clause

  • 디스크스페이스에서 디스크 제거를 선언할 때 사용

  • 리밸런스를 수행하기 전까지 디스크가 제거되지 않음

rebalance_diskspace_clause

디스크스페이스에 저장된 데이터를 이동시켜서 실제 디스크의 추가 또는 제거를 수행

disk_online_clause

  • 오프라인 상태인 디스크를 온라인 상태로 바꿀 때 사용

  • 오프라인 상태였던 디스크는 데이터 동기화 과정을 거쳐 온라인 상태가 됨

disk_offline_clause

  • 온라인 상태인 디스크를 오프라인 상태로 바꿀 때 사용

  • 오프라인 상태로 바뀐 디스크는 그 즉시 읽기와 쓰기가 중단됨

drop_diskspace_file_clause

디스크스페이스에 저장된 사용자 파일을 제거할 때 사용

scrub_clause

  • 디스크스페이스에 저장된 사용자 데이터를 클리닝할 때 사용

  • NORMAL 또는 HIGH의 중복 레벨로 생성된 디스크스페이스에 대해, 자동으로 데이터 커럽션을 확인하고 복구할 수 있음

add_thread_clause

디스크스페이스에 클러스터 구성을 위한 스레드를 추가할 때 사용

– add_disk_clause

구성요소
설명

FAILGROUP failgroup_name

  • 디스크가 속할 failgroup 이름을 명시

  • 디스크스페이스의 중복 레벨이 NORMAL 또는 HIGH인 경우에만 유효하며, 알파벳과 숫자 등으로 최대 48자를 사용할 수 있음

  • 명시하지 않은 경우에는 모든 디스크가 각각 하나의 failgroup으로 구성되며 디스크 이름이 failgroup 이름으로 사용됨

DISK qualified_disk_clause

디스크스페이스에 추가할 디스크를 정의

– qualified_disk_clause

구성요소
설명

search_string

  • 디스크스페이스를 구성할 디스크의 경로를 명시

  • 와일드카드를 사용하여 여러 디스크를 나열할 수 있으며, TAS_DISKSTRING 초기화 파라미터로 찾을 수 있는 경로이어야 함

NAME disk_name

  • search_string으로 찾은 디스크의 이름을 명시

  • search_string으로 찾은 디스크가 한 개인 경우에만 지정할 수 있으며, 알파벳과 숫자 등으로 최대 48자를 사용할 수 있음

  • 디스크의 이름은 TAS 내에서만 사용되며 디스크 경로와는 무관

  • 명시하지 않은 경우 임의로 생성된 이름이 사용됨

SIZE

  • search_string으로 찾은 디스크의 크기를 byte 단위로 명시

  • search_string으로 찾은 디스크가 여러 개인 경우 모든 디스크가 같은 크기로 지정

  • 명시하지 않을 경우 TAS에서 파악한 실제 디스크의 크기가 지정됨

  • TAS에서 실제 디스크 크기를 알 수 없는 경우 오류가 발생하며, 이때는 반드시 디스크 크기를 명시해 주어야 함

FORCE

  • search_string으로 찾은 디스크가 이미 다른 디스크스페이스에 사용 중이더라도 이를 무시하고 새로은 디스크스페이스 구성에 사용

  • 기존 디스크스페이스를 파기하는 경우에 명시

NOFORCE

  • search_string으로 찾은 디스크가 이미 다른 디스크스페이스에 사용 중인 경우 오류가 발생

  • FORCE 또는 NOFORCE가 명시되지 않은 경우의 기본 동작

– drop_disk_clause

구성요소
설명

DISK disk_name

제거할 디스크 이름을 명시

FORCE

  • 리밸런스를 기다리지 않고 디스크스페이스에서 즉시 디스크를 제거

  • 이후 리밸런스는 중복 저장된 다른 복제본으로 수행

  • 디스크 장애로 인해 읽기가 불가능한 디스크를 제거할 때 사용

NOFORCE

  • 리밸런스 완료 후 디스크가 완전히 제거됨

  • FORCE/NOFORCE를 명시하지 않은 경우의 기본 동작

DISKS IN FAILGROUP failgroup_name

지정된 failgroup에 속한 모든 디스크를 제거할 때 사용

– rebalance_diskspace_clause

구성요소
설명

POWER integer

  • 리밸런스의 수행 속도를 0에서 11 사이의 값으로 지정

  • 지정된 숫자가 클수록 리밸런스가 빨리 끝나지만, 저장된 데이터의 동시성이 떨어짐됨

  • 명시하지 않은 경우 자동으로 결정

WAIT

리밸런스가 완전히 끝날 때까지 대기

NOWAIT

  • 리밸런스를 시작하고 대기하지 않음

  • 명령이 성공했더라도 리밸런스가 진행 중일 수 있음

– disk_online_clause

구성요소
설명

DISK disk_name

온라인 상태로 변경할 디스크의 이름을 명시

DISKS IN FAILGROUP failgroup_name

지정된 failgroup에 속한 모든 디스크를 온라인 상태로 변경할 때 사용

ALL

오프라인 상태인 모든 디스크를 온라인 상태로 변경할 때 사용

POWER integer

  • 오프라인 상태였던 디스크에 대해 데이터 동기화 속도를 1에서 11 사이의 값으로 지정

  • 지정된 숫자가 클수록 동기화가 빨리 끝나지만, 저장된 데이터의 동시성이 떨어짐

WAIT

동기화가 완전히 끝날 때까지 대기

NOWAIT

  • 동기화를 시작하고 대기하지 않음

  • WAIT를 명시하지 않은 경우의 기본 동작

  • 명령이 성공했더라도 동기화가 진행 중일 수 있음

– disk_offline_clause

구성요소
설명

DISK disk_name

오프라인 상태로 변경할 디스크의 이름을 명시

DISKS IN FAILGROUP failgroup_name

지정된 failgroup에 속한 모든 디스크를 오프라인 상태로 변경할 때 사용

– drop_diskspace_file_clause

구성요소
설명

FILE 'filename'

삭제할 파일의 이름을 명시

– scrub_clause

구성요소
설명

FILE 'filename'

  • 클리닝을 수행할 파일의 이름을 명시

  • 명시하지 않으면 디스크스페이스 의 모든 파일에 대해 클리닝을 수행

REPAIR

복제본과 같지 않은 데이터가 발견될 경우 데이터를 동기화

NOREPAIR

  • 복제본과 같지 않은 데이터가 발견되면 Dump만 출력하고 데이터를 동기화하지 않음

  • REPAIR를 명시하지 않은 경우의 기본 동작

  • TRACE_DUMP_DEST 초기화 파라미터에 지정된 경로에 Dump가 출력됨

POWER integer

  • 데이터 클리닝 속도를 1에서 11 사이의 값으로 지정

  • 지정된 숫자가 클수록 클리닝이 빨리 끝나지만, 저장된 데이터의 동시성이 떨어짐

WAIT

클리닝이 완전히 끝날 때까지 대기

NOWAIT

  • 클리닝을 시작하고 대기하지 않음

  • WAIT을 명시하지 않은 경우의 기본 동작

  • 명령이 성공했더라도 클리닝이 진행 중일 수 있음

FORCE

전체 시스템의 IO 부하에 관계 없이 클리닝을 수행

NOFORCE

  • 전체 시스템의 IO 부하가 큰 경우 클리닝을 수행하지 않

  • FORCE를 명시하지 않은 경우의 기본 동작

– add_thread_clause

구성요소
설명

thread_number

  • 추가할 Thread 번호를 명시

  • Thread는 TAS 인스턴스를 클러스터로 구 성할 때 사용되며, THREAD 초기화 파라미터로 지정해 사용

  • 예제

다음은 ALTER DISKSPACE를 사용해 여러 개의 디스크를 추가, 제거하고 리밸런스를 수행하는 예입니다.

다음은 앞의 디스크 추가, 제거 작업을 하나의 문장으로 수행하는 예입니다.

다음은 ALTER DISKSPACE를 사용해 디스크를 온라인 상태로 변경하는 예입니다.

다음은 ALTER DISKSPACE를 사용해 디스크를 오프라인 상태로 변경하는 예입니다.

다음은 ALTER DISKSPACE를 사용해 디스크스페이스의 사용자 파일을 삭제하는 예입니다.

circle-exclamation

주의

7.2.1 부터는 DROP FILE 기능이 기본적으로 금지되어 있습니다.

자세한 내용은 'Tibero Active Storage 관리자 안내서'를 참조합니다.

다음은 ALTER DISKSPACE를 사용해 스레드를 추가하는 예입니다.

hashtag
ALTER FUNCTION

지정된 tbPSM 함수를 재컴파일합니다. ALTER PROCEDURE 문과 유사합니다. 일반적으로 SQL 문장에 포함 된 tbPSM 함수가 유효하지 않으면, SQL 문장을 실행할 때 자동으로 재컴파일됩니다. tbPSM 함수 또는 프 러시저의 유효성에 대해서는 "Tibero tbPSM 안내서"를 참고합니다.

ALTER FUNCTION은 객체의 유효성 여부에 상관없이 재컴파일을 시도합니다. 이 과정에서 직간접적으로 종속 관계를 가지는 모든 부모 객체를 재귀적으로 검사하여 유효하지 않을 경우 재컴파일을 시도합니다. 또 한 직간접적으로 종속된 모든 자식 객체를 무효화합니다. 자세한 내용은 “ALTER PROCEDURE”를 참고합니다.

ALTER FUNCTION의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

tbPSM 함수를 재컴파일하는 사용자가 대상 함수를 소유하고 있거나, ALTER ANY PROCEDURE 시스템 특권을 부여 받아야 합니다.

  • 구성요소

구성요소
설명

schema

해당 함수가 속해 있는 스키마의 이름을 명시

function_name

해당 함수의 이름을 명시

  • 예제

다음은 ALTER FUNCTION을 사용해 tbPSM 함수를 컴파일하는 예입니다.

hashtag
ALTER INDEX

인덱스의 속성을 변경합니다. 인덱스를 다시 만들거나, 인덱스의 이름을 변경할 때도 사용됩니다.

ALTER INDEX의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

다음 중 하나를 만족해야 ALTER INDEX 문을 실행할 수 있습니다.

  • 인덱스가 ALTER INDEX 문을 실행하는 사용자의 스키마에 포함되어 있습니다.

  • ALTER ANY INDEX 시스템 특권이 있습니다.

  • 구성요소

구성요소
설명

schema

  • 인덱스나 테이블의 스키마의 이름

  • 생략하면 현재 사용자의 스키마로 인식

index_name

변경할 인덱스의 이름을 명시

RENAME

  • 인덱스를 다시 만들지 않고, 이름을 변경

  • 인덱스의 파티션(PARTI TION) 또는 서브 파티션(SUBPARTITION)의 이름도 변경할 수 있음

new_name

  • 인덱스의 새로운 이름

  • 스키마의 이름을 지정할 수 없으므로, 스키마 를 이동할 수 없음

PARTITION

파티션의 이름을 변경하고자 할 때 사용

partition_name

변경할 파티션의 이름을 명시

SUBPARTITION

서브 파티션의 이름을 변경하고자 할 때 사용

subpartition_name

변경할 서브 파티션의 이름을 명시

REBUILD

  • 인덱스를 다시 생성

  • 인덱스 효율이 좋지 않거나, 비활성화되어 있던 인덱스를 다시 사용하고자 할 때 사용

  • 인덱스 생성이 완료되면 비활성화되어 있던 인덱스는 다시 활성화됨

REVERSE

  • REBUILD의 옵션

  • 인덱스 블록의 바이트 순서를 순차에서 역순으로 다시 배정

  • 지정하지 않으면 인덱스의 기존 바이트 순서와 동일하게 재생성

NOREVERSE

  • REBUILD의 옵션

  • 인덱스 블록의 바이트 순서를 기존 순서와 동일하게 재생성

ONLINE

  • REBUILD의 옵션

  • 인덱스를 재생성하는 동안 해당 테이블에 DML을 수행할 수 있도록 함

COALESCE

인덱스의 비어 있는 블록을 재사용하기 위해 인덱스 블록의 내용을 모아서 저장

MONITORING USAGE

  • 인덱스 사용 여부를 모니터링

  • 모니터링 결과는 V$OBJECT_USAGE를 조회하여 확인할 수 있음

NOMONITORING USAGE

인덱스 사용 여부 모니터링을 중지

INITRANS unsigned_integer

  • 인덱스 블록의 트랜잭션 엔트리(Transaction Entry)를 위한 공간을 최초 몇 개 확보할지 설정

  • 트랜잭션 엔트리는 필요할 때마다 확장됨

  • 따라서 미리 큰 값을 반드시 설정할 필요는 없음

INVISIBLE

  • 인덱스의 상태 옵션

  • 인덱스의 VISIBLE과 INVISIBLE 여부는 OPTIMIZER가 해당 인덱스를 고려하는지 여부와 관련이 있음

  • INVISIBLE 상태의 인덱스는 DML 작업과 일반 인덱스처럼 형태를 계속 유지

  • 하지만 Optimizer에서 고려할 대상으로 여기지 않음

  • 제약 사항

ALTER INDEX 문의 수행에는 다음과 같은 제약사항이 있습니다.

  • Functional Index에 대한 REBUILD ONLINE REVERSE는 수행할 수 없습니다.

  • REBUILD ONLINE 수행 도중 실패하거나 중단되었을 경우 반드시 DBMS_REPAIR 패키지의 ON LINE_INDEX_CLEAN 함수를 통해 인덱스 online-rebuild에 대한 클린업을 수행해야 합니다.

  • 예제

다음은 RENAME을 사용해 생성된 인덱스의 이름을 변경하는 예입니다.

다음은 REBUILD를 사용해 인덱스를 재생성하는 예입니다.

다음은 NOREVERSE 옵션과 ONLINE 옵션을 지정하여 인덱스를 재생성하는 예입니다.

다음은 COALESCE를 사용하는 예입니다.

다음은 MONITORING USAGE를 사용하는 예입니다.

hashtag

hashtag
ALTER MATERIALIZED VIEW

이미 생성된 실체화 뷰를 변경합니다.

ALTER MATERIALIZED VIEW의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

    • 사용자가 소유한 스키마의 실체화 뷰를 변경하기 위해서는 별다른 특권이 필요하지 않습니다.

    • 다른 사용자가 소유한 스키마의 실체화 뷰를 변경하기 위해서는 ALTER ANY MATERIALIZED 시스 템 특권이 있어야 합니다.

  • 구성요소

– alter_materialized_view

구성요소
설명

alter_mv_refresh

  • 실제화 뷰에 대한 리프레시(Refresh) 방법, 모드, 시간 등을 지정

  • 실제화 뷰가 참조하는 테이블에 변경이 발생하면, 테이블의 현재 데이터를 반영하기 위해 실제화 뷰를 리프레시

  • 이 문장을 이용하여 데이터베이스가 실제화 뷰를 리프레시하는 스케줄, 모드, 방법 등을 조절할 수 있음

ENABLE

실제화 뷰를 질의 다시 쓰기에 사용될 수 있는 상태로 설정 (기본값)

DISABLE

실제화 뷰를 질의 다시 쓰기에 사용될 수 없는 상태로 설정

QUERY REWRITE

실제화 뷰가 질의 다시 쓰기에 사용될 지의 여부를 설정

– alter_mv_refresh

구성요소
설명

FAST

빠른 리프레시를 수행하려고 할 때 사용

COMPLETE

  • 실제화 뷰를 정의하는 질의를 재수행하여 완전 리프레시를 사용

  • COMPLETE가 명시되면 빠른 리프레시가 가능하더라도 완전 리프레시를 사용 (기본값)

FORCE

빠른 리프레시가 가능하면 빠른 리프레시를 수행하고, 그렇지 않으면 완전 리프레시를 수행

ON DEMAND

사용자가 DBMS_MVIEW 패키지의 REFRESH 프로시저를 호출하는 경우에만 리프레시를 수행(기본값)

ON COMMIT

  • ON COMMIT이 명시된 경우 마스터 테이블에 커밋이 일어날 때마다 리프레시를 수행

  • 하지만, START WITH와 NEXT는 명시할 수 없음

  • ON COMMIT과 ON DEMAND는 동시에 명시할 수 없음

START WITH

  • 처음으로 자동 리프레시가 시작될 날짜형 표현식을 명시

  • START WITH는 미래의 시간을 나타내는 값이어야 함

  • NEXT 없이 START WITH만을 명시할 경우 데이터베이스는 한 번만 리프레시를 수행

NEXT

  • 자동 리프레시의 간격을 계산하기 위한 날짜형 표현식을 명시

  • NEXT는 미래의 시간을 나타내는 값이어야 함

  • START WITH 없이 NEXT만 명시한 경우 데이터베이스는 NEXT 표현식을 평가하여 첫 리프레시의 시간을 정함

date

START WITH와 NEXT에 지정할 날짜형 리터럴을 명시

WITH PRIMARY KEY

PRIMARY KEY를 사용하여 리프레시를 수행

WITH ROWID

ROWID를 사용하여 리프레시를 수행

NEVER REFRESH

자동 리프레시를 하지 않음

  • 예제

다음은 ALTER MATERIALIZED VIEW를 사용해 실체화 뷰를 변경하는 예입니다.

위의 예에서는 START WITH와 NEXT 절을 이용하여 기존의 실체화 뷰를 10분마다 자동으로 리프레시 하는 실체화 뷰로 변경하였습니다. 단위가 날짜이기 때문에 분 단위로 설정하기 위해 1440(24X60 = 1440) 으로 나누었습니다.

hashtag
ALTER MATERIALIZED VIEW LOG

지정된 마스터 테이블의 실체화 뷰 로그를 변경합니다.

ALTER MATERIALIZED VIEW LOG의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

다음 중 하나를 만족해야 ALTER MATERIALIZED VIEW LOG 문을 실행할 수 있습니다.

  • 마스터 테이블을 사용자가 소유하고 있어야 합니다.

  • 마스터 테이블에 SELECT 권한과 ALTER 권한이 모두 있어야 합니다.

  • 구성요소

– alter_materialized_view_log

구성요소
설명

FORCE

실체화 뷰 로그에 이미 존재하는 속성의 추가를 명시하여도 에러를 발생 시키지 않고 존재하지 않는 속성만을 추가

schema

  • 변경할 실체화 뷰 로그에 마스터 테이블의 스키마를 명시

  • 생략하면 현재 사용자의 스키마로 인식됨

table

변경할 실체화 뷰 로그의 마스터 테이블의 이름을 명시

PRIMARY KEY

실체화 뷰 로그에 마스터 테이블의 변경된 로우의 PRIMARY KEY를 기록

ROWID

실체화 뷰 로그에 마스터 테이블의 변경된 로우의 ROWID를 기록

SEQUENCE

실체화 뷰 로그에 마스터 테이블의 변경된 로우의 SEQUENCE를 기록

column

실체화 뷰 로그에 기록할 마스터 테이블의 컬럼을 지정

– new_values_clause

구성요소
설명

INCLUDING NEW VALUES

실체화 뷰 로그에 컬럼의 변경 전/후의 값을 모두 기록

EXCLUDING NEW VALUES

실체화 뷰 로그에 컬럼의 변경 전의 값만을 기록 (기본값)

  • 예제

다음은 ALTER MATERIALIZED VIEW LOG를 사용해 실체화 뷰 로그를 변경하는 예입니다.

hashtag
ALTER PACKAGE

ALTER PACKAGE를 사용해 명시적으로 PACKAGE의 SPECIFICATION과 BODY 또는 둘 다를 재컴파일 할 수 있습니다. 명시적으로 재컴파일을 수행하면 런타임 때 발생할 수 있는 암묵적인 재컴파일을 막을 수 있 다. 따라서 오버헤드와 컴파일 에러를 미연에 방지할 수가 있습니다.

하나의 PACKAGE는 전체가 하나의 단위로 취급되기 때문에, ALTER PACKAGE 문은 PACKAGE 안에 포함된 프러시저나 함수 모두를 재컴파일합니다. ALTER PROCEDURE나 ALTER FUNCTION을 사용해 PACKAGE 안에 포함된 PROCEDURE와 FUNCTION을 개별적으로 재컴파일하는 방법은 없습니다.

부모 객체에 대한 재컴파일과 자식 객체에 대한 무효화에 대한 자세한 내용은 “ALTER PROCEDURE”를 참고합니다.

ALTER PACKAGE의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

PACKAGE가 자신의 스키마에 포함되어 있거나, ALTER ANY PROCEDURE 시스템 특권이 있어야 한 다.

  • 구성요소

구성요소
설명

qualified_obj_name

재컴파일할 PACKAGE의 이름을 명시

PACKAGE

  • 디폴트로 생략할 수 있으며, PACKAGE SPECIFICATION과 PACKAGE BODY가 모두 재컴파일

  • PACKAGE가 직간접적으로 종속 관계를 맺는 부모 객체를 모두 재귀적으로 검사하여 필요하면 재컴파일을 실행해 유효화 과정을 거

  • PACKAGE에 직간접적으로 종속되는 모든 자식 객체를 무효화(PACKAGE BODY는 다른 객체 그리고 명세에 종속)

SPECIFICATION

  • 명세(PACKAGE SPECIFICATION)만 재컴파일됨

  • PACKAGE SPECIFICATION은 다른 객체에 종속되는 자식 객체가 될 수 없으므로, 오직 명세에 대한 컴파일만 일어남

  • PACKAGE SPECIFICATION에 직간접적으로 종속되는 자식 객체를 모두 무효로 함

  • PACKAGE BODY 또한 이런 자식 객체에 포함됨

  • 무효화된 PACKAGE BODY는 다음에 사용될 때 자동으로 재컴파일됨

BODY

  • PACKAGE BODY이 직간접적으로 종속 관계를 가지는 모든 무효화된 부모 객체를 재컴파일

  • 명세가 무효화되어 있습니다면 재컴파일됨

  • PACKAGE 옵션과 다른 점은 BODY 옵션은 명세가 무효화 상태일 때만 재컴파일이 일어남

  • 본문에 직간접적으로 종속되는 모든 자식 객체를 무효화

  • BODY 옵션은 PACKAGE BODY를 다시 작성했거나, PACKAGE BODY만 무효화되었을 때 사용됨

  • 예제

다음은 ALTER PACKAGE를 사용해 PACKAGE를 재컴파일하는 예입니다.

hashtag

hashtag
ALTER PROCEDURE

지정된 tbPSM 프러시저를 재컴파일합니다. 일반적으로 SQL 문장에 포함된 tbPSM 프러시저가 유효하지 않으면, SQL 문장을 실행할 때 재컴파일됩니다.

프러시저의 재컴파일은 DDL에 준하는 작업이 수행되는 것이므로 수행하려고 했던 SQL의 처리 속도에 영향을 줄 수 있습니다. 또한, 자동으로 재컴파일을 하는 도중에 다른 무효화된 스키마 객체에 의해 컴파일의 수행이 실패할 수도 있습니다. 이럴 때 SQL 문장의 처리도 당연히 실패합니다. 때문에 SQL 문장을 실행할 때 재 컴파일이 되는 것을 원하지 않을 수 있습니다. 이럴 때 DBA나 사용자는 ALTER PROCEDURE 문을 미리 호출 하여 무효화된 객체를 다시 유효하게 만들 수 있습니다.

ALTER PROCEDURE 문을 호출했을 때 재컴파일하는 단계는 다음과 같습니다.

단계
설명

1

  • 프러시저가 종속성을 갖는 모든 부모 객체를 찾은 다음 상태가 무효화(INVALID)이면 재컴파 일을 시도

  • 각각의 객체는 다시 상태가 유효화(VALID)되어 데이터 사전의 관련 정보가 갱신되고 커밋

  • 부모 객체를 재컴파일하는 과정에서 그 객체의 부모 객체는 각각 재귀적으로 컴파일됨

  • 이 중 하나라도 실패하면 ALTER PROCEDURE 문의 대상인 객체의 컴파일은 실패

2

  • 재컴파일된 모든 객체에 종속되는 자식 객체는 모두 상태가 무효화(INVALID)가 됨

  • 상태가 무효화된 객체는 다음번에 사용될 때 자동으로 재컴파일 되어 상태가 유효화(VALID)하게 변경될 수 있음

3

ALTER PROCEDURE 문장의 대상 객체는 상태의 유효여부에 상관없이 재컴파일되며, 자식 객체는 재귀적으로 모두 상태가 무효화(INVALID)가 됨

circle-info

참고 ALTER PROCEDURE 문의 재컴파일 과정과 유효화, 무효화 과정은 ALTER FUNCTION 문과 ALTER PACKAGE 문과 ALTER TYPE 문에서도 동일하게 적용됩니다.

ALTER PROCEDURE의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

사용자가 소유한 프러시저이거나 ALTER ANY PROCEDURE 시스템 특권을 부여받아야 합니다.

  • 구성요소

구성요소
설명

schema

프러시저가 속해 있는 스키마의 이름을 명시

procedure_name

재컴파일을 진행할 프러시저의 이름을 명시

  • 예제

hashtag

hashtag
ALTER PROFILE

프로파일의 속성을 변경합니다.

circle-info

참고

프로파일을 생성, 제거하기 위해서는 “CREATE PROFILE”와 “DROP PROFILE”의 내용 을 참고합니다.

ALTER PROFILE의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

ALTER PROFILE 시스템 특권이 있어야 합니다.

  • 구성요소

구성요소
설명

profile_name

변경할 프로파일의 이름을 명시

password_paramenters

변경할 프로파일 속성을 지정

hashtag

hashtag
ALTER ROLE

ROLE의 패스워드를 변경합니다. ROLE에 포함된 특권 등은 GRANT나 REVOKE를 사용하여 부여하거나 회수하고, ALTER ROLE로는 단순히 ROLE의 패스워드만을 변경합니다.

circle-info

참고

ROLE의 추가와 제거에 대해서는 “CREATE ROLE”, “DROP ROLE”을 참고합니다.

ALTER ROLE의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

    • ALTER ROLE로 ROLE의 패스워드를 변경하는 것은 해당 ROLE을 생성한 사용자이거나, WITH ADMIN OPTION으로 관리 특권을 부여 받은 사용자에 한해 가능합니다.

    • ALTER ANY ROLE 시스템 특권이 있는 사용자는 자신이 생성하지도 않고, 관리 특권을 부여받지 않 은 ROLE의 패스워드도 변경할 수 있습니다.

  • 구성요소

구성요소
설명

role_name

  • 패스워드를 변경할 ROLE의 이름

  • 해당 ROLE은 이미 CREATE ROLE 을 통해 만들어져 있어야 함

NOT IDENTIFIED

ROLE의 패스워드를 제거

IDENTIFIED BY

ROLE의 패스워드를 변경

password

변경할 패스워드를 입력

  • 예제

다음은 ALTER ROLE을 사용해 ROLE의 패스워드를 변경하는 예입니다.

위의 예를 보면 우선 CREATE ROLE을 사용하여 패스워드를 지정하지 않고 ROLE을 생성합니다. 그 다 음 생성된 ROLE을 ALTER ROLE을 사용하여, 패스워드를 'xxx'로 지정했다가 다시 제거하고 있습니다.

참고

패스워드 사용과 관련된 예는 “CREATE ROLE”이나 “SET ROLE”을 참고합니다.

hashtag
ALTER ROLLBACK SEGMENT

Undo segment를 최소 크기 또는 지정한 크기만큼 줄인다. 단, undo segment에 undo retention 시간이 지 난 재사용 가능 공간이 없거나 실행 중인 트랜잭션이 많은 경우 해당 undo segment의 공간을 줄이지 못할 수도 있습니다.

ALTER ROLLBACK SEGMENT의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

ALTER ROLLBACK SEGMENT 시스템 특권이 있어야 합니다.

  • 구성요소

구성요소
설명

unsigned_integer

undo segment 번호를 명시

size

undo segment의 크기를 지정 (단위: byte)

hashtag

hashtag
ALTER SEQUENCE

지정된 시퀀스의 정의를 변경합니다.

circle-info

참고

시퀀스의 생성과 제거에 대해서는 “CREATE SEQUENCE”와 “DROP SEQUENCE”를 참고합니다.

ALTER SEQUENCE의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

시퀀스가 사용자가 소유한 스키마에 있거나, ALTER_ANY_SEQUENCE 시스템 특권을 부여받아야 합니다.

  • 구성요소

구성요소
설명

schema

  • 변경할 시퀀스를 포함하는 스키마의 이름

  • 생략하면 현재 사용자의 스키마로 인식됨

sequence_name

  • 변경할 시퀀스의 이름

  • 시퀀스의 이름은 VARCHAR 타입으로 저장되고 길이는 최대 30자까지 가능

  • 시퀀스의 이름은 테이블과 같은 네임스페이스를 사용

  • 따라서 스키마의 다른 시퀀스, 테이블, 동의어, PSM의 이름과 중복되어서는 안 됨

sequence_attributes

  • ALTER SEQUENCE를 사용해 이미 존재하는 시퀀스의 증가값, 최소값, 최대값, 저장해 놓은 시퀀스 번호의 개수 등을 변경할 수 있고, 시퀀스의 속성을 변경할 수 있음

  • 이러한 변경 사항은 앞으로 생성될 시퀀스 번호에만 적용

  • sequence_attributes에 캐시를 사용하는 경우 ALTER SEQUENCE에 의해 몇 개의 값이 누락될 수 있음

  • ALTER SEQUENCE를 사용하면 이미 시퀀스 캐시에 존재하던 값을 모두 무효화시켜 버리기 때문

  • START WITH는 변경할 수 없음

  • 자세한 내용은 “CREATE SEQUENCE”의 sequence_attributes를 참고

  • 예제

다음은 “CREATE SEQUENCE”의 예제에서 생성한 test_seq라는 시퀀스의 속성을 변경하는 예이 다.

hashtag

hashtag
ALTER SYNONYM

현재 존재하는 SYNONYM의 상태를 수정할 때 사용합니다.

ALTER SYNONYM의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

– 자신의 SCHEMA 내에 있는 SYNONYM에 대해서는 특권이 필요 없으며, 다른 SCHEMA의 SYNONYM을 수정하기 위해서는 CREATE ANY SYNONYM과 DROP ANY SYNONYM 특권이 있어야 합니다.

– PUBLIC SYNONYM을 수정하기 위해서는 CREATE PUBLIC SYNONYM과 DROP PUBLIC SYNONYM 특권이 있어야 합니다.

  • 구성요소

– alter_synonym

구성요소
설명

PUBLIC

PUBLIC SYNONYM에 대한 수정을 함

COMPILE

  • SYNONYM을 revalidate

  • SYNONYM의 target object의 status가 invalid일 경우 해당 object의 recompile 로직을 수행하고, 그 외의 경우 에는 SYNONYM의 status는 target object의 status를 그대로 취함

  • 예제

다음은 ALTER SYNONYM COMPILE을 사용하여 SYNONYM을 컴파일하는 예입니다.

다음은 ALTER PUBLIC SYNONYM COMPILE을 사용했을 때 권한이 없는 경우 에러가 발생하는 예이 다.

hashtag

hashtag
ALTER TABLE

생성된 테이블을 변경합니다.

ALTER TABLE의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

사용자가 소유한 스키마의 테이블을 변경하기 위해서는 별다른 특권은 필요하지 않다. 다만, 다른 사용 자의 스키마의 테이블을 변경하기 위해서는 ALTER ANY TABLE 시스템 특권이 있어야 합니다.

  • 구성요소

– alter_table

구성요소
설명

schema

  • 변경할 테이블이 속해 있는 스키마의 이름을 명시

  • 생략하면 현재 사용자의 스키마로 인식됨

table_name

변경할 테이블의 이름을 명시

alter_table_properties

PCTFREE, INITRANS, storage_clause 등 물리적인 속성을 변경

atbl_con_alterstate_cl

제약조건의 상태를 변경할 때 사용

alter_table_partitioning

  • 파티션 테이블에만 사용할 수 있음

  • 파티션 테이블에 관련된 설명은 “CREATE TABLE”을 참고

column_clause

테이블의 컬럼을 추가, 수정, 제거

constraint_clause

테이블의 제약조건을 추가, 수정, 제거

move_table_clause

테이블에 대해 물리적인 속성을 새로 지정하여 세그먼트를 생성한 후 기존 테이블을 새 세그먼트로 이동시킴

– alter_table_properties

구성요소
설명

physical_attributes_clause

PCTFREE, INITRANS, storage_clause 등 물리적인 속성을 변경

table_compression

테이블의 압축을 여부를 지정

parallel_clause

테이블에 대한 DML을 수행할 때 참조할 기본 DOP(Degree of Parallelism)을 설정

RENAME

테이블의 이름을 변경

TO identifier

변경할 테이블의 새 이름을 지정

READ ONLY

테이블을 READ ONLY 모드로 지정

READ WRITE

테이블을 READ WRITE 모드로 지정

REKEY encryption_spec

  • REKEY는 데이터베이스가 새로운 암호화 키를 생성하도록 함

  • ALTER TABLE에서 다른 문장과 혼용될 수 없음

  • 테이블의 모든 암호화된 컬럼이 새로운 키로 암호화되고, encryption_spec에 USING을 사용할 경우 새로운 암호화 알고리즘으로 암호화됨

ADD OVERFLOW

IOT 테이블에 Overflow Segment를 추가

– physical_attributes_clause

구성요소
설명

PCTFREE unsigned_integer

  • 데이터를 디스크 블록에 저장할 때 데이터가 변경되어 크기가 증가할 것에 대비하여 얼마만큼의 영역을 예비로 남겨둘지를 설정하는 값

  • 1 ~ 99 사이의 값을 설정할 수 있으며, 지정하지 않으면 기본값은 10

  • unsigned_integer에 해당 값을 명시

INITRANS unsigned_integer

  • 디스크 블록마다 트랜잭션 엔트리를 위한 공간을 몇 개를 확보할 것인지를 나타냄

  • 트랜잭션 엔트리는 블록에 공간이 남아있다면 필요할 때 확장됨

  • 따라서 미리 큰 값을 설정할 필요는 없음

  • 최소값은 1이며, 최댓값은 디스크 블록의 크기에 따라 다르다. 지정하지 않으면 기본값은 2

  • unsigned_integer에 해당 값을 명시

storage_clause

  • 세그먼트의 세부적인 속성을 정의

  • 자세한 내용은 “Storage_clause”를 참고

– table_compression

구성요소
설명

COMPRESS

DPI/DPL을 사용 중일 때만 테이블을 압축

NOCOMPRESS

테이블을 압축하지 않음

COMPRESS FOR OLTP

DPI/DPL이 아닌 일반 DML일 때만 테이블을 압축

COMPRESS FOR DIRECT_LOAD OPERATIONS

DPI/DPL을 사용 중일 때만 테이블을 압축

COMPRESS FOR ALL OPERATIONS

모든 DML에 대해 테이블을 압축

ROW STORE COMPRESS ADVANCED

DPI/DPL이 아닌 일반 DML일 때만 테이블을 압축

COMPRESSED TABLE에서는 DROP COLUMN, SET UNUSED, DROP UNUSED COLUMNS 구문을 사용할 수 없습니다.

COMPRESSED TABLE에서 MERGE, SPLIT 파티션 시 UPDATE GLOBAL INDEXES, UPDATE INDEXES 구문도 지원하지 않습니다.

– row_movement_clause

구성요소
설명

ENABLE ROW MOVEMENT

  • 데이터베이스가 ROW를 이동하도록 허용

  • 따라서 ROWID가 변경 될 수 있음

DISABLE ROW MOVEMENT

데이터베이스가 ROW를 이동하도록 허용하지 않음

– alter_table_partitioning

구성요소
설명

add_table_partition

  • 파티션 테이블의 마지막 파티션 뒤에 새 파티션을 추가

  • 기존의 파티셔닝 방법에 맞게 파티션을 추가해야 함

  • 파티션의 이름은 지정하 지 않으면 자동으로 생성됨 – RANGE 파티션의 경우: 새 파티션의 경계 값이 맨 마지막의 파티션보 다 커야 함. 따라서 MAXVALUE 값을 가진 파티션이 있으면 파티션 을 추가할 수 없음. – LIST 파티션의 경우: 새 파티션의 파티셔닝 키 값에 기존 파티션에 들어간 값이 중복되지 않아야 하며, 테이블에 기본값을 가진 파티션이 있는 경우에는 파티션을 추가할 수 없음.현재 HASH 파티션 테이블에 대해서는 파티션 추가를 지원하지 않음.

drop_partition_subpart

  • 주어진 이름의 파티션 또는 서브 파티션을 제거

  • 단, 파티션 또는 서브 파티션이 마지막 하나만 남아 있는 경우에는 제거할 수 없음

modify_table_partition

기존 파티션의 구조를 변경

  • 서브 파티션 추가: 복합 파티션 테이블에서만 사용할 수 있으며, 기존 서브 파티셔닝 방법에 맞게 파티션을 추가해야 함. 서브 파티션의 이름을 지정하지 않으면 자동으로 생성됨. 제약 사항은 add_ta ble_partition과 동일하며, 자세한 문법은 'sub_partition_desc'를 참고.

  • LIST 파티션/서브 파티션의 값 추가 및 삭제 (ADD VALUES, DROP VALUES): LIST 파티션이나 LIST 서브 파티션에 새로운 값을 추가하 거나 기존 값을 제거할 수 있음. 추가되는 값은 다른 파티션이나 서브 파티션의 값과 중복될 수 없으며, 삭제 시에는 해당 파티션/서브 파티 션에 존재하는 값이어야 함.

  • 파티션 속성 변경 (table_partition_desc): 특정 파티션의 물리적 속성 을 변경할 수 있음. 테이블 속성 변경 구문과 유사하나, 대상이 파티션 이라는 점만 다름.

move_partition_subpart

  • 주어진 이름의 파티션 또는 서브 파티션에 대해 물리적 속성을 새로 지 정하여 세그먼트를 생성한 후 기존 파티션을 새 세그먼트로 이동시킴

  • 기본 파티션 테이블의 파티션과 복합 파티션 테이블의 서브 파티션을 사용할 수 있음

rename_partition_subpart

주어진 이름의 파티션 또는 서브 파티션의 이름을 변경

split_table_partition

기존 파티션을 분할

HASH 파티션 테이블에는 사용할 수 없음

  • RANGE 파티션의 경우: AT을 사용하여 파티셔닝 키의 경계 값을 지 정하면 그 값을 기준으로 파티션이 두 개로 분할. 따라서 AT에서 지정하는 값이 분할하는 파티션이 가지는 범위 안에 있어야 함.

  • LIST 파티션의 경우: VALUES를 사용하여 파티셔닝 키 값을 지정하며, 지정한 값을 포함하는 파티션과 그 외 나머지 값을 포함하는 파티션으로 분할됨. 따라서 VALUES 절에서 지정하는 값이 분할하는 파티션의 기존 키 값에 존재해야 하며, 기존 파티셔닝 키 값 전부를 지 정할 수는 없음. 분할하는 파티션이 서브 파티션을 가진 경우에는 기존과 동일한 기준으로 서브 파티션을 생성합니다.

split_table_subpartition

  • 기존 서브 파티션을 분할

  • 서브 파티셔닝 방법은 해시 파티셔닝이 아닌 복합 파티션 테이블에서 사용할 수 있음

  • 서브 파티션을 분할합니다는 것과 SUBPARTITION 예약어를 사용합니다는 것 외에는 'split_table_partition'과 동일

merge_table_partition

두 개의 파티션을 하나의 파티션으로 합침

exchange_table_partition

주어진 파티션과 테이블의 세그먼트를 교환

modify_table_default_attrs

테이블의 기본 attribute들을 변경

truncate_table_partition

  • 파티션에 존재하는 모든 ROW를 제거

  • 만약 파티션이 서브 파티션 을 가지고 있습니다면, 포함하는 모든 서브 파티션의 ROW가 제거됨

  • 서브 파티션의 이름을 주면 해당하는 서브 파티션의 모든 ROW가 제거됨

set_interval_value

  • Range 파티션의 Interval 값을 변경

  • 파티션 테이블에 DML이 발생할 때, 파티션 키 컬럼 값에 해당하는 파티션이 없을 경우 새로운 파티션을 만들어 줌

  • 이 때, 기준 값에서 Interval value로 지정한 값의 배수로 새로 만들 파티션의 기준 값이 결정됨

  • ALTER TABLE 명령으로 interval value를 변경할 경우 Range 파티션의 마지막 파티션 값이 기준값이 됨

  • 최초의 경우 CREATE TABLE 명령 에서 명시한 파티션 중 마지막 파티션이 기준값으로 이용됨

– add_table_partition

구성요소
설명

partition_name

추가할 파티션의 이름을 명시

range_partition_desc

RANGE 파티션의 세부적인 설정을 지정

list_partition_desc

LIST 파티션의 세부적인 설정을 지정

hash_partition_desc

HASH 파티션의 세부적인 설정을 지정

– drop_partition_subpart

구성요소
설명

PARTITION

파티션을 제거할 때 명시

partition_name

제거할 파티션의 이름을 명시

SUBPARTITION

서브 파티션을 제거할 때 명시

subpartition_name

제거할 서브 파티션의 이름을 명시

UPDATE GLOBAL INDEXES

GLOBAL INDEX들을 업데이트

INVALIDATE GLOBAL INDEXES

GLOBAL INDEX들을 Invalid 상태로 변경

UPDATE INDEXES

지정한 INDEX들을 업데이트

– modify_table_partition

구성요소
설명

partition_name

변경할 파티션의 이름을 명시

ADD

  • 서브 파티션을 추가하거나, LIST 파티션/서브 파티션에 새로운 값을 추가(서브 파티션 추가는 현재 LIST-HASH나 RANGE-HASH와 같이 서브 파티셔닝 방법이 HASH인 경우 지원 안함)

DROP

LIST 파티션/서브 파티션에서 값을 제거

range_subpartition_desc

RANGE 파티션의 세부적인 설정을 지정

list_subpartition_desc

LIST 파티션의 세부적인 설정을 지정

hash_subpartition_desc

HASH 파티션의 세부적인 설정을 지정

table_partition_desc

  • 파티션의 물리적인 속성을 지정

  • 문법은 테이블의 속성을 지정할 때와 유사하며, 파티션의 속성을 지정합니다는 것만 다름

list_values_desc

LIST 파티션/서브 파티션에 추가하거나 삭제할 값들을 지정

– move_partition_subpart

구성요소
설명

PARTITION

파티션을 이동할 때 명시

partition_name

이동할 파티션의 이름을 명시

SUBPARTITION

서브 파티션을 이동할 때 명시

subpartition_name

이동할 서브 파티션을 명시

table_partition_desc

  • 파티션의 물리적인 속성을 지정

  • 지정하는 방법은 테이블의 속성을 지정할 때와 유사하며, 파티션의 속성을 지정합니다는 것만 다름

– rename_partition_subpart

구성요소
설명

PARTITION partition_name

변경할 대상 파티션의 이름을 명시

subpartition_name

변경할 대상 서브 파티션의 이름을 명시

TO new_name

변경할 파티션의 새로운 이름을 명시

– split_table_partition

구성요소
설명

partition_name

분할할 파티션의 이름을 명시

AT literal

RANGE 파티션의 경우 AT을 사용하여 파티셔닝 키의 경계 값을 지정한 다. literal에 지정하는 값을 기준으로 파티션이 두 개로 분할

INTO range_partition_desc

분할할 파티션의 이름과 속성을 지정

VALUES literal

  • LIST 파티션의 경우 VALUES를 사용하여 파티셔닝 키 값을 지정하며, 지정한 값을 포함하는 파티션과 그 이외의 값을 갖는 파티션으로 분할

  • literal에 지정하는 값은 파티션의 기존 키 값으로 존재해야 하며, 기본 파티셔닝 키 값 전부를 지정할 수는 없음

INTO list_partition_desc

분할할 파티션의 이름과 속성을 지정

– split_table_subpartition

구성요소
설명

partition_name

분할할 서브 파티션의 이름을 명시합니다.

AT literal

RANGE 파티션의 경우 AT을 사용하여 파티셔닝 키의 경계 값을 지정한 다. literal에 지정하는 값을 기준으로 파티션이 두 개로 분할됩니다.

INTO range_subpartition_desc

분할할 서브 파티션의 이름과 속성을 지정합니다.

VALUES literal

LIST 서브 파티션의 경우 VALUES를 사용하여 파티셔닝 키 값을 지정 하며, 지정한 값을 포함하는 서브 파티션과 그 이외의 값을 갖는 서브 파 티션으로 분할됩니다. literal에 지정하는 값은 서브 파티션의 기존 키 값으 로 존재해야 하며, 기본 파티셔닝 키 값 전부를 지정할 수는 없습니다.

INTO list_subpartition_desc

분할할 서브 파티션의 이름과 속성을 지정합니다.

– exchange_table_partition

구성요소
설명

partition_name

파티션 혹은 서브 파티션의 이름을 명시

table_name

파티션과 세그먼트를 교환할 테이블의 이름을 명시

INCLUDING INDEXES

로컬 인덱스 파티션 또는 서브 파티션을 해당 테이블 인덱스(파티션되지 않은 테이블의 경우) 또는 로컬 인덱스(해시 파티션된 테이블의 경우)와 교환하도록 하려면 지정

EXCLUDING INDEXES

  • 파티션에 해당하는 모든 인덱스 파티션 또는 서브 파티션과 표시할 교환 테이블의 모든 일반 인덱스 및 인덱스 파티션을 원하는지 여부를 지정

  • INCLUDING INDEXES, EXCLUDING INDEXES를 명시하지 않으면 기본으로 EXCLUDING INDEXES를 수행

WITH VALIDATION

  • 테이블의 Row들이 파티션 조건, 제약 조건 등에 맞는지 체크를 한 후 맞지 않습니다면, 에러를 발생시킴

  • WITH VALIDATION, WITHOUT VALIDATION을 명시하지 않으면 기본으로 VALIDATION을 수행

WITHOUT VALIDATION

테이블의 Row들이 파티션 조건, 제약 조건등과 맞지 않아도 세그먼트 교환을 수행

– modify_table_default_attrs

구성요소
설명

partition_name

파티션 혹은 서브 파티션의 이름을 명시

sgmt_attr

sgmt_attr 관련 문법은 “Sgmt_attr”을 참고

– merge_table_partition

구성요소
설명

first_partition_name

합병될 첫 번째 파티션의 이름을 명시

second_partition_name

  • 합병될 두 번째 파티션의 이름을 명시

  • range partition의 경우 첫 번 째 partition의 바로 다음 파티션이 지정되어야 함

INTO partition_desc

합병으로 만들어질 파티션의 이름과 속성을 지정

– truncate_table_partition

구성요소
설명

PARTITION partition_name

분할할 파티션의 이름을 명시

SUBPARTITION subpartition_name

분할할 서브 파티션의 이름을 명시

DROP STORAGE

  • 파티션이 사용하고 있는 공간을 회수

  • 즉, 할당받은 EXTENTS들을 모두 회수

  • 별도로 지정하지 않으면 기본적으로 DROP STORAGE로 동작

REUSE STORAGE

파티션이 사용하고 있는 공간을 회수하지 않고, 그대로 사용

– column_clause

구성요소
설명

add_column_clause

  • 테이블에 새로운 컬럼을 추가

  • 이전에 존재하던 다른 로우의 컬럼은 디폴트로 설정한 값이 삽입됨

  • 만약 디폴트가 설정되어 있지 않으면 NULL 값이 삽입됨

  • Inline 제약조건으로 설정하면 이전에 이미 삽입된 컬럼을 대상으로 검증을 하게 되므로, 만족하지 않는 경우 컬럼 추가 자체가 실패할 수도 있음

  • 만약 LONG 타입의 컬럼이 존재하는 테이블이라면 새로운 컬럼을 추가할 수 없음

modify_column_clause

  • 테이블에 이미 존재하는 컬럼의 속성을 변경

  • 데이터 타입, 기본값, Inline 제약조건, Inline 참조 제약조건(Inline Referential Constraint)을 변경

rename_column_clause

컬럼의 이름을 변경

drop_column_clause

  • 테이블에 이미 존재하는 컬럼을 제거

  • 컬럼만 제거되는 것이 아니라 제거되는 컬럼과 관련된 인덱스, 트리거, 주석 등도 같이 제거됨

modify_lob_storage_clause

  • 테이블에 이미 존재하는 LOB 컬럼의 속성을 변경

  • Cache 사용 여부, Logging 사용 여부를 변경

REKEY encryption_spec

  • REKEY는 데이터베이스가 새로운 암호화 키를 생성하도록 함

  • ALTER TABLE에서 다른 문장과 혼용될 수 없음

  • 테이블의 모든 암호화 된 컬럼이 새로운 키로 암호화되고, encryption_spec에 USING을 사용 할 경우 새로운 암호화 알고리즘으로 암호화됨

– add_column_clause

구성요소
설명

coldef

  • 컬럼의 데이터 타입과 제약조건 등을 설정

  • coldef 관련 문법은 “CREATE TABLE”을 참고

colprop

  • 컬럼별로 대용량 객체형 데이터 타입이 저장되는 방식을 설정

  • col prop 관련 문법은 “CREATE TABLE”을 참고

– modify_column_clause

구성요소
설명

datatype

  • 컬럼의 데이터 타입을 변경

  • NUMBER 타입을 CLOB 타입으로 바꾸는 등의 변경은 허락되지 않음

  • NUMBER 타입에서 정밀도나 스케일을 늘리거나, VARCHAR 타입 에서 컬럼의 길이를 늘리는 것은 항상 허용됨

  • 하지만, NUMBER 타 입의 정밀도나 스케일을 줄이기 위해서는 해당 컬럼의 데이터가 전부 NULL이거나 값이 없어야 하고, CHAR, VARCHAR 타입의 컬럼의 길이를 줄이기 위해서는 줄이고자 하는 길이보다 더 큰 컬럼 값이 존재하지 않아야 함

DEFAULT

컬럼의 기본값을 변경

inline_constraint

Inline 제약조건을 추가 또는 변경할 수 있음

– rename_column_clause

구성요소
설명

old_colname

  • RENAME COLUMN은 기존 컬럼의 이름을 변경할 때 사용

  • old_colname에는 이름을 변경하고 싶은 컬럼의 기존 이름을 명시

TO new_colname

new_colname에는 이름을 변경하고 싶은 컬럼의 새로운 이름을 명시

– drop_column_clause

구성요소
설명

column_name

제거할 컬럼의 이름을 명시

CONSTRAINTS

  • 제약조건이 있는 컬럼을 제거하기 위해서 사용

  • 단, 파티션 테이블 에서 파티셔닝 키로 사용되고 있는 컬럼은 제거할 수 없음

INVALIDATE

  • INVALIDATE은 지정하지 않아도 됨

  • 제거한 컬럼이 있는 테이블과 관련된 뷰, 트리거 등이 자동으로 무효화되기 때문

  • 무효화된 객체는 다음번에 사용될 때 다시 검증됨

– modify_lob_storage_clause

구성요소
설명

column_name

변경할 LOB 컬럼의 이름을 명시

modify_lob_parameters

변경될 LOB의 저장 속성을 명시

– modify_lob_parameters

구성요소
설명

cache_clause

LOB 컬럼을 cache를 사용해서 읽을 것인지 명시

logging_clause

  • LOB 컬럼에 작업을 할 때 redo log를 남길 것인지 지정

  • cache option을 사용할 경우 항상 logging을 사용하여야 함

– constraint_clause

구성요소
설명

ADD outofline constraint

  • 새로운 outofline 제약조건을 추가

  • outofline 제약조건과 관련된 문 법은 “제약조건”을 참고

RENAME CONSTRAINT

기존 제약조건의 이름을 변경

old_name

old_name에는 이름을 변경하고 싶은 제약조건의 기존 이름을 명시

TO new_name

new_name에는 이름을 변경하고 싶은 제약조건의 새로운 이름을 명시

MODIFY

기존 제약조건의 상태를 변경

DROP

기존의 제약조건을 제거

constraint_state

constraint_state 등의 관련 문법은 “제약조건”을 참고

PRIMARY KEY

변경되거나 제거될 기본 키를 의미

UNIQUE column_name

변경되거나 제거될 유일 키를 의미

CONSTRAINT name

변경되거나 제거될 제약조건을 의미

CASCADE

  • 다른 테이블이나 같은 테이블의 컬럼으로부터 FOREIGN KEY 제약조건으로 참조되는 기본 키나 유일 키 제약조건을 제거하기 위해서는 반드시 CASCADE를 설정하여 관련된 FOREIGN KEY까지 함께 제거해야함만

  • FOREIGN KEY로 참조되는 상태에서 기본 키나 유일 키만 단독으로 제거할 수는 없음

KEEP INDEX

  • 기본 키, 유일 키, FOREIGN KEY와 같은 인덱스를 사용하는 제약조건을 제거하려 할 때 제약조건만 제거하고 해당 제약조건이 사용했던 인덱스는 그대로 유지하고자 할 때 사용

DROP INDEX

  • 기본 키, 유일 키, FOREIGN KEY와 같은 인덱스를 사용하는 제약조건을 제거하려 할 때 인덱스도 함께 제거하기 위해서 사용

  • KEEP INDEX나 DROP INDEX를 설정하지 않으면, DROP INDEX가 기본값

– list_values_desc

구성요소
설명

VALUES

  • LIST 파티션/서브 파티션이 담당할 키 값을 지정

  • (와 )로 묶어 여러 개의 값을 나열할 수 있

list_values

  • 실제로 지정되는 값들의 집합

  • 값은 쉼표(,)로 구분하며, 숫자, 문자 열, 날짜 등 파티셔닝 키 타입에 맞는 리터럴을 사용

  • 예제

– physical_attributes_clause

다음은 테이블을 생성한 뒤에 PCTFREE와 INITRANS를 사용하는 예입니다.

다음은 atbl_con_alterstate_cl를 사용하는 예입니다.

– column_clause

다음은 column_clause를 사용하는 예입니다.

위의 예에서는 차례대로 add_column_clause, rename_column_clause, modify_column_clause를 사 용하는 것을 보여줍니다.

다음은 add_column_clause와 modify_column_clause를 사용하는 예입니다.

다음은 rename_column_clause를 사용하는 예입니다.

– alter_table_partitioning

다음은 alter_table_partitioning을 사용하는 예입니다.

hashtag

hashtag
ALTER TABLESPACE

테이블 스페이스 또는 데이터 파일의 특성을 변경합니다.

ALTER TABLESPACE의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

SYSDBA 특권이 있어야 합니다.

  • 구성요소

– alter_tablespace

구성요소
설명

alter_ts_datafile_clause

테이블 스페이스에 속해 있는 파일의 특성을 변경

alter_ts_state_clause

테이블 스페이스의 특성을 변경

alter_ts_logging_clause

테이블 스페이스의 logging에 대한 설정을 변경

SHRINK SPACE

  • 임시 테이블 스페이스의 임시 파일들의 사용하지 않은 공간을 버려 전체 파일들의 크기를 축소시킴

  • 임시 테이블 스페이스(Temporary Tablespace)일 때 사용

  • KEEP을 지정하면 최소 지정한 KEEP 크기 만큼 남기고 전체 파일을 축소시킴

– alter_ts_datafile_clause

구성요소
설명

ADD DATAFILE

  • 데이터 파일을 추가할 때 사용

  • 영속 테이블 스페이스(Permanent Tablespace) 또는 Undo 테이블 스페이스일 때 사용

  • 추가할 데이터 파일의 이름을 하나라도 지정하지 않으면, Tibero 시스템이 자동으로 데이터 파일을 생성하여 추가

ADD TEMPFILE

  • 임시 파일을 추가할 때 사용

  • 임시 테이블 스페이스(Temporary Tablespace)일 때 사용

  • 추가할 임시 파일의 이름을 하나도 지정하지 않으면 Tibero 시스템이 자동으로 임시 파일을 생성하여 추가

dfspec

  • 데이터 파일의 이름, 크기 등과 관련된 설정을 할 수 있음

  • 자세한 내용은 “CREATE DATABASE”를 참고

RENAME DATAFILE

  • 미디어 복구 중 데이터 파일의 경로를 바꾸고자 할 때 사용

  • 영속 테이블 스페이스 또는 Undo 테이블 스페이스일 때 사용

RENAME TEMPFILE

  • 미디어 복구 중 임시 파일의 경로를 바꾸고자 할 때 사용

  • 임시 테이블 스페이스일 때 사용

DROP DATAFILE

  • 데이터 파일을 삭제할 때 사용

  • 삭제할 파일은 내용이 비어있는 상태여야 함

SHRINK TEMPFILE

  • 임시 파일의 크기를 축소시킴

  • 임시 테이블 스페이스(Temporary Tablespace)일 때 사용

  • [KEEP size]는 축소시킬 수 있는 파일 크기의 하한을 나타냄

  • 지정해주지 않으면 0으로 설정됨

– alter_ts_state_clause

구성요소
설명

BEGIN BACKUP

  • 데이터베이스 운영 중 백업을 시작할 때 사용됨

  • 자세한 내용은 "Tibero 관리자 안내서"를 참고

END BACKUP

  • 데이터베이스 백업을 끝낼 때 사용

  • 자세한 내용은 "Tibero 관리자 안내서"를 참고

OFFLINE

  • 테이블 스페이스를 오프라인 상태로 변경

  • 테이블 스페이스가 오프라인 상태가 되면 테이블 스페이스에 속한 세그먼트로의 접근은 모두 차단됨

  • 또한, 테이블 스페이스가 가진 모든 데이타 파일 도 오프라인 상태가 됨 – OFFLINE NORMAL: 해당 테이블 스페이스에 체크포인트를 수행한 후 오 프라인 상태로 변경. 온라인 상태로 다시 전환할 때 복구 과정을 거치지 않음. NORMAL이나 IMMEDIATE를 지정하지 않으면 NORMAL로 동작. – OFFLINE IMMEDIATE: NORMAL과 달리 체크포인트를 수행하지 않고 바로 오프라인 상태로 변경하기 때문에 온라인 상태로 전환하기 전에 미디어 복구를 해야 함.

ONLINE

  • 테이블 스페이스를 온라인 상태로 변경

  • 테이블 스페이스 복구가 필요하면 바로 온라인 상태로 변경할 수 없음

  • 미디 어 복구를 해야만 온라인 상태로 변경할 수 있음

WAIT

  • 테이블 스페이스 변경을 위한 lock 획득을 기다림

  • 테이블 스페이스 변경을 위해서는 테이블 스페이스 lock을 획득해야 함

  • 기본 세팅의 경우 현재 다른 작업이 lock을 획득한 상태라면 lock 획득 실패라고 인지하고 DDL 구문 역시 실패 처리됨

  • WAIT 옵션을 주면 lock을 획득할 때까지 기다린 뒤에 구문을 수행

– alter_ts_logging_clause

구성요소
설명

LOGGING / NOLOG GING

테이블 스페이스 내에 있는 오브젝트들에 대한 logging 설정을 하는 데 사용

  • LOGGING: 오브젝트들에 대한 작업이 redo log로 남음

  • NOLOGGING: 오브젝트들에 대한 작업이 redo log로 남지 않음. ALTER TABLESPACE로 logging 설정이 변경된 이후의 시점부터 해당 logging 에 대한 설정이 적용.

FORCE LOGGING / NO FORCE LOGGING

  • FORCE LOGGING: 테이블 스페이스 내에 있는 오브젝트들에 대한 작업 이 logging이 되며, 기존에 nologging으로 설정이 되어있었어도 logging이 됨

  • NO FORCE LOGGING: FORCE LOGGING 설정을 제거하는 기능. 단, 무조건 LOGGING을 하는 UNDO 테이블 스페이스와 LOGGING을 하지 않는 TEMP 테이블 스페이스에 대해서는 force logging 설정이 불가능.

  • 예제

다음은 테이블 스페이스에 데이터 파일을 추가하는 예입니다. 본 예제에서는 DBA_TABLESPACES를 통 해 테이블 스페이스가 사용하는 데이터 파일의 개수를 알 수 있습니다.

hashtag

hashtag
ALTER TRIGGER

데이터베이스 트리거를 컴파일하거나 트리거의 이름을 바꾼다. 또한, 해당 트리거를 활성화하거나 비활 성화합니다.

ALTER TRIGGER의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

사용자의 스키마에 포함되어 있거나, 사용자가 ALTER ANY TRIGGER 시스템 특권을 가지고 있을 때 에만 실행할 수 있습니다.

  • 구성요소

– alter_trigger

구성요소
설명

RENAME

  • 트리거의 이름을 변경

  • 변경된 트리거는 이전의 상태를 계속 유지하게 됨

COMPILE

  • 트리거를 명시적으로 재컴파일

  • 명시적으로 재컴파일을 하면 런타임을 수행할 때 발생할 수 있는 암묵적인 재컴파일을 막을 수 있고, 오버헤드와 컴파일 에러를 미리 방지할 수가 있음

  • Tibero는 트리거가 참조하는 객체가 무효화된 상태이면 재컴파일을 한 뒤, 트 리거를 컴파일

  • 트리거가 성공적으로 컴파일되면 해당 트리거는 유효함

–enable_option

구성요소
설명

ENABLE

트리거를 활성화

DISABLE

트리거를 비활성화

  • 예제

다음은 트리거를 비활성화하는 예입니다.

hashtag

hashtag
ALTER TYPE

ALTER TYPE를 사용해 명시적으로 사용자 정의 타입을 재컴파일할 수 있습니다.

명시적으로 재컴파일을 수행하면 런타임 때 발생할 수 있는 암묵적인 재컴파일을 막을 수 있습니다. 따라서 오 버헤드와 컴파일 에러를 미연에 방지할 수가 있습니다. 부모 객체에 대한 재컴파일과 자식 객체에 대한 무효화 의 자세한 내용은 “ALTER PROCEDURE”를 참고합니다.

ALTER TYPE의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

사용자가 소유한 사용자 정의 타입이거나, ALTER ANY TYPE 시스템 특권을 부여받아야 합니다.

  • 구성요소

구성요소
설명

schema

사용자 정의 타입이 속해 있는 스키마의 이름을 명시

type_name

재컴파일을 진행할 사용자 타입의 이름을 명시

SPECIFICATION/BODY

  • 스펙과 바디 모두를 재컴파일할지 바디만 재컴파일할지를 지정

  • 옵션을 주지 않으면 스펙과 바디 모두를 재컴파일

  • 예제

hashtag

hashtag
ALTER USER

사용자의 정보를 변경합니다.

circle-info

참고

사용자를 생성, 제거하기 위해서는 “CREATE USER”와 “DROP USER”의 내용을 참고합니다.

ALTER USER의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

ALTER USER 시스템 특권이 있어야 합니다. 단, 사용자가 자신의 패스워드를 변경할 때는 제외입니다.

  • 구성요소

–alter_user

구성요소
설명

username

  • 변경할 사용자의 이름

  • 변경할 사용자는 CREATE USER로 미리 만들어져 있어야 함

alter_user_clause

  • 변경할 사용자의 정보

  • CREATE USER와는 다르게 생략할 수 없고, 반드시 하나 이상은 있어야 함

proxy_user_clause

  • Proxy user를 사용하기 위해 설정하는 정보

  • CREATE USER 이후에 추가적으로 해당 사용자에 대한 proxy 접근 설정을 원할 때 있어야 함

–alter_user_clause

구성요소
설명

IDENTIFIED BY

  • 사용자의 인증 패스워드를 변경

  • ALTER USER 시스템 특권이 있는 경우에만 다른 사용자의 패스워드를 변경할 수 있음

  • REPLACE 절은 무시됨

VALUES 'password_hash_value'

  • Hash value로 encrypt된 password로 user의 비밀번호를 변경

  • Sys권한에서만 변경이 가능

new_password

  • 변경될 새로운 패스워드를 입력

  • 패스워드는 문자열로 지정하며, 길이는 63bytes까지 가능

REPLACE

  • old_password를 기존 패스워드와 비교하여 같은 경우에만 변경을 허용

old_password

  • 변경 전의 기존 패스워드를 입력

  • 패스워드는 문자열로 지정하며, 길이는 63bytes까지 가능

DEFAULT TABLESPACE

  • 사용자가 사용할 디폴트 테이블 스페이스를 변경

  • CREATE TABLE을 사용하여 테이블을 생성할 때 테이블 스페이스를 명시하지 않으면 디폴트 테이블 스페이스를 사용하게 됨

PASSWORD EXPIRE

  • 사용자의 패스워드를 사용기간 만료 상태로 변경

  • 패스워드가 사용기간 만료 상태가 되면 해당 사용자가 다음에 접속했을 때, 패스워드 사용기간이 만료되었다는 메시지가 출력되고 패스워드를 변경해야 함

ACCOUNT LOCK

  • 사용자를 잠금 상태로 변경

  • 사용자가 잠금 상태로 변경되면 해당 사용자는 데이터베이스를 사용할 수 없음

ACCOUNT UNLOCK

사용자를 잠금 해제 상태로 변경

디폴트 역할을 지정하는 방법은 다음과 같이 3가지가 있습니다.

번호
옵션
설명

1

role_name

  • 부여받은 역할 중에 디폴트 역할로 지정할 역할을 나열하는 방식

  • 이는 몇 가지 역할만을 사용하고자 할 때 유용

2

ALL (EXCEPT)

  • ALL은 거의 대부분의 역할을 디폴트 역할로 사용하고자 할 때 유용

  • 몇몇 역할을 제외한 나머지 역할 모두를 디폴트 역할로 하고자 한다면, ALL 뒤에 EXCEPT를 사용하여 제외하고자 하는 역할을 명시할 수 있음

3

NONE

  • NONE은 디폴트 역할을 모두 끄고 필요한 역할만 활성화시켜서 사용하고자 할 때 유용

  • 부여받은 역할 중 디폴트 역할에서 제외된 역할은 SET ROLE 문을 사용하여 동적으로 켜거나 끌 수 있음

  • 자세한 내용은 “SET ROLE”을 참고

– tsquota_clause

구성요소
설명

QUOTA size ON tablespace_name

사용자가 사용할 테이블 스페이스의 크기를 지정 값 만큼 제한

QUOTA UNLIMITED ON tablespace_name

사용자가 사용할 테이블 스페이스의 크기를 제한하지 않음

– proxy_user_clause

구성요소
설명

GRANT

  • 사용자에 proxy 접속 권한을 줄 때 사용

  • 해당 권한을 받은 proxy user에 대해서만 사용자로 접속 가능

REVOKE

  • 사용자에 proxy 접속 권한을 철회할 때 사용

  • 해당 권한이 철회된 proxy user는 사용자로 접속이 불가능하게 됨

CONNECT THROUGH

  • Proxy 접속 기능을 사용할 때 사용하는 구문

  • CONNECT THROUGH 구문 다음에 나오는 username이 proxy user가 됨

  • 예제

다음은 IDENTIFIED BY를 사용해 사용자의 패스워드를 변경하는 예입니다.

다음은 DEFAULT TABLESPACE를 사용해 디폴트 테이블 스페이스를 변경하는 예입니다.

다음은 DEFAULT ROLE을 사용해 디폴트 역할을 변경하는 예입니다.

위의 예를 보면, 처음에 CREATE ROLE 문을 사용하여 A, B, C 이렇게 3개의 역할을 만든다. 그리고 GRANT 문을 사용하여 역할 B에게 역할 A의 특권을 부여한 뒤, 역할 B와 C를 사용자 u1에게 부여합니다. 그 상태에서 사용자 U1에게 부여된 역할을 조회합니다. 그리고 사용자 u1의 디폴트 역할을 역할 B에 부여 된 역할 A로 지정하려 하면 사용자 u1이 역할 A를 직접 부여받은 적이 없기 때문에 에러가 발생하게 된 다.

사용자 u1에게 역할 A까지 부여한 뒤 DEFAULT ROLE NONE을 사용해 디폴트 역할을 모두 제거합니다. 그리고 다시 사용자 u1에게 부여된 역할을 조회하면 모든 디폴트 역할이 꺼져있음을 확인할 수 있습니다. 마지막으로 DEFAULT ROLE ALL을 사용해 보유한 역할을 모두 디폴트 역할로 설정합니다. EXCEPT를 같이 사용하여 역할 A, C를 제외한 나머지 모든 역할을 디폴트 역할로 지정하고 있습니다.

다음은 PASSWORD EXPIRE를 사용해 사용자의 패스워드를 만료시키는 예입니다.

다음은 ACCOUNT를 사용해 사용자를 잠금 상태와 잠금 해제 상태로 변경하는 예입니다.

hashtag

hashtag
ALTER VIEW

무효화된 뷰를 다시 컴파일합니다. 이 명령어를 사용하기 위하여 자신의 스키마에 포함된 뷰이거나 ALTER ANY TABLE 시스템 특권을 부여 받고 있어야 합니다.

ALTER TABLE 명령을 이용하여 테이블을 변경한 경우 그 테이블에 기반한 모든 뷰는 무효화됩니다. 무효 화된 뷰는 SQL 문장 내에서 사용될 때에 자동으로 다시 컴파일됩니다. ALTER VIEW 명령어는 SQL 문장 내 에서 사용되기 전에 미리 다시 컴파일하여 성능 저하를 막고 가능한 문제를 미리 발견하기 위하여 사용한 다.

ALTER VIEW의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

ALTER VIEW로 뷰를 갱신하기 위해서는 자기 스키마에 속한 뷰거나 ALTER ANY VIEW 시스템 특권이 필요합니다.

  • 구성요소

구성요소
설명

schema

  • 다시 컴파일할 뷰를 포함하는 스키마의 이름

  • 만약 생략하면 현재 사용자의 스키마를 가정

view_name

뷰의 이름을 설정

COMPILE

  • 다시 컴파일하도록 함

  • 유효하지 않은 뷰를 다시 유효하게 만들어 주거나, 참조하는 뷰나 테이블의 정의가 바뀌었을 경우 알맞게 뷰의 정의를 변경

  • 예제

hashtag

hashtag
AUDIT

사용자가 시스템 특권 또는 스키마 객체 특권을 사용하는 것을 감사합니다. 감사하고 있는 특권을 해제하기 위해서는 “NOAUDIT”의 내용을 참고합니다. 특권에 대한 자세한 내용은 "Tibero 관리자 안내서"를 참 고합니다.

AUDIT의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

    • 시스템 특권을 감사하기 위해서는 AUDIT SYSTEM 시스템 특권을 부여받아야 합니다.

    • 다른 사용자가 소유한 스키마의 객체 또는 디렉터리 객체를 감사하기 위해서는 AUDIT ANY 시스템 특권을 부여받아야 합니다.

    • 감사한 내용을 기록하기 위해서는 $TB_SID.tip 파일에 AUDIT_TRAIL 파라미터가 NONE이 아닌 다 른 옵션으로 설정해야 합니다. NONE이 설정되어 있으면, 감사를 하더라도 기록은 하지 않습니다.

    • SYS 사용자는 기본으로 감사되지 않습니다. SYS 사용자를 감사하기 위해서는 $TB_SID.tip 파일의 AUDIT_SYS_OPERATIONS 파라미터를 Y로 설정합니다. 그러면 SYS 사용자가 수행한 동작이 모두 기록됩니다.

  • 구성요소

– audit

구성요소
설명

audit_operation_clause

시스템 특권을 감사

audit_schema_object_clause

  • 특정 객체에 대한 스키마 객체 특권을 감사

  • 감사할 수 있는 객 체의 종류는 테이블, 뷰, 시퀀스, 프러시저, 디렉터리 등

BY SESSION

  • 감사 대상이 되는 권한을 사용했을 경우 이를 어떻게 기록할 것인지를 지정

  • BY SESSION은 같은 위반을 세션 당 한 번만 기록

BY ACCESS

  • BY ACCESS는 같은 위반이라도 매번 기록

  • $TB_SID.tip 파일의 AUDIT_TRAIL 파라미터의 값이 OS이면 BY SESSION은 무시되고 항상 BY ACCESS로 동작

  • 생략하면 기본값은 BY ACCESS

WHENEVER SUCCESSFUL

  • 감사 대상이 되는 권한을 사용했을 경우 해당 명령의 성공이나 실패 여부에 따라 어떻게 기록할 것인지를 지정

  • WHENEVER SUCCESSFUL은 명령이 성공했을 때만 기록

  • 지정하지 않으면 성공이나 실패에 관계없이 모두 기록

WHENEVER NOT SUCCESSFUL

WHENEVER NOT SUCCESSFUL은 명령이 실패했을 때만 기록을 저장

– audit_operation_clause

구성요소
설명

system_privilege

  • 감사할 시스템 특권을 지정

  • 시스템 특권의 종류는 “GRANT”의 시스템 특권을 참고

ALL PRIVILEGES

모든 시스템 특권을 감사

BY user_name

  • 감사할 사용자를 지정

  • 지정하지 않으면 모든 사용자에 적용

– audit_schema_object_clause

구성요소
설명

object_privilege

  • 감사할 스키마 객체 특권을 지정

  • 스키마 객체 특권의 종류는 “GRANT”의 시스템 특권을 참고

ALL

  • 해당 객체에 사용할 수 있는 모든 스키마 객체 특권을 감사

  • 대상 객체의 종류에 따라 사용할 수 있는 스키마 객체 특권은 “GRANT”의 시스템 특권을 참고

ON

  • 스키마 객체 특권을 감사할 대상이 되는 객체를 지정

schema

  • 객체가 속해 있는 스키마의 이름을 지정

  • 스키마 이름을 지정하지 않으면, 자신의 스키마 객체에서 해당 이름을 찾음

object_name

디렉터리가 아닌 객체의 이름을 지정

DIRECTORY dir_name

디렉터리 객체의 이름을 지정

  • 예제

– audit

다음은 BY SESSION을 사용해 감사 기록 여부를 설정하는 예입니다.

– audit_operation_clause

다음은 BY user_name을 사용해 감사할 사용자를 지정하는 예입니다.

– audit_schema_object_clause

다음은 ON을 사용해 스키마 객체 특권을 감사할 대상 객체를 지정하는 예입니다.

hashtag

hashtag
COMMENT

테이블, 뷰 또는 이에 속한 특정 컬럼에 주석을 삽입합니다.

COMMENT의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

사용자가 소유한 스키마 객체에 COMMENT 문을 실행하는 경우 별다른 특권이 필요하지 않습니다. 하지만, 다른 사용자에게 속한 스키마 객체라면 COMMENT ANY TABLE 시스템 특권이 필요합니다.

  • 구성요소

구성요소
설명

TABLE

  • 테이블이나 뷰에 주석을 삽입할 때 사용

  • 삽입된 주석의 내용은 나중에 DBA_TAB_COMMENTS, USER_TAB_COMMENTS, ALL_TAB_COMMENTS 전적 뷰로 확인할 수 있음

COLUMN

  • 테이블, 뷰에 속한 컬럼에 주석을 삽입하고 싶을 때 사용

  • 삽입한 주석의 내용은 나중에 DBA_COL_COMMENTS, USER_COL_COMMENTS, ALL_COL_COMMENTS 전적 뷰로 확인할 수 있음

comment_string

  • 주석의 내용

  • 주석은 VARCHAR 타입으로 저장되므로, 최대 4000자까지 입력할 수 있음

  • 예제

다음은 COMMENT를 사용해 주석을 삽입하는 예입니다.

hashtag

hashtag
CREATE CONTEXT

문맥 네임스페이스를 생성(혹은 수정)하고 해당 네임스페이스의 문맥을 조작할 수 있는 패키지를 지정한 다. 지정된 패키지에서 DBMS_SESSION.SET_CONTEXT 프로시져를 사용해 해당 네임스페이스의 속성 값들을 설정할 수 있습니다.

CREATE CONTEXT의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

문맥 네임스페이스를 생성하기 위해서는 CREATE ANY CONTEXT 시스템 특권이 있어야만 합니다.

  • 구성요소

– create_context_clause

구성요소
설명

namespace

생성(하거나 수정)할 문맥 네임스페이스의 이름을 명시

schema

  • 문맥을 조작할 패키지의 스키마를 명시

  • 스키마를 생략하면 현재 스키마를 가정

package_name

  • 문맥을 조작할 패키지의 이름을 명시

  • 패키지가 현재 존재하지 않더라도 해당 DDL 은 정상 수행됨

ACCESSED GLOBALLY

이것을 명시하면 데이터베이스 인스턴스가 살아 있는 한 모든 세션에서 해당 문맥에 접근하여 내용을 읽을 수가 있음

  • 예제

다음은 CREATE CONTEXT를 사용해 문맥을 생성하는 예입니다. 보안 정책을 구현한 패키지는 pol_pkg이며, 문맥 네임스페이스의 이름은 sec_ctx 입니다.

hashtag

hashtag
CREATE CONTROLFILE

기존에 존재하는 데이터 파일과 로그 파일의 정보를 바탕으로 컨트롤 파일을 새로 생성합니다. 최대 데이터 파일의 개수를 변경하는 경우나 컨트롤 파일이 손상된 경우에 사용하며, NOMOUNT 모드에서만 사용할 수 있습니다. 일반적으로 ALTER DATABASE BACKUP CONTROLFILE TO TRACE를 이용하여 컨트롤 파일 의 생성문을 백업합니다.

CREATE CONTROLFILE의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

Tibero를 NOMOUNT 모드로 기동하면, SYS 사용자만 CREATE CONTROLFILE 문을 실행할 수 있습니다.

  • 구성요소

– create_controlfile

구성요소
설명

REUSE

기존에 존재하는 컨트롤 파일에 덮어쓰고자 할 경우에 사용

DATABASE

컨트롤 파일을 생성하고자 하는 대상 데이터베이스를 명시

database_name

대상 데이터베이스의 이름을 명시

create_ctrlf_clasuse

컨트롤 파일의 다양한 속성을 설정

– create_ctrlf_clasuse

구성요소
설명

LOGFILE

  • 온라인 로그 파일을 지정

  • 온라인 로그 파일은 두 개 이상의 로그 그룹을 정의하고, 그룹별로 하나 이상의 멤버를 지정해야 함

log_member_clause

  • 로그 그룹에 번호를 지정할 수 있음

  • 지정하지 않으면 0부터 차례대로 지정됨

RESETLOGS

  • RESETLOGS를 명시하면 기존 로그 파일을 무시하고 로그를 초기화

  • RESETLOGS를 명시하지 않으면 NORESETLOGS로 간주

NORESETLOGS

  • NORESETLOGS를 명시하면 기존의 유효한 로그 파일을 계속 사용함

  • 로그 파일이 반드시 존재해야 하고, 계속 사용하는 Redo 로그 파일이어야 함

MAXDATAFILES

  • 데이터베이스에서 사용할 최대 데이터 파일의 개수를 제한

  • MAXDATAFILES에 지정된 값만큼 컨트롤 파일에 데이터 파일의 공간을 만듦

  • 따라서 MAXDATAFILES의 값을 초과하는 데이터 파일의 개수를 정의할 수 없음

  • MAXDATAFILES의 값을 변경하려면 컨트롤 파일을 재생성해야 함

  • MAXDATAFILES의 값이 클수록 많은 메모리가 요구되므로, 이 점을 고려해서 값을 설정해야 함(기본값: 100, 최소값: 10, 최댓값: 65533)

MAXINSTANCES

  • 데이터베이스에서 사용할 최대 인스턴스 개수를 제한

  • MAXINSTANCES에 지정된 값만큼 컨트롤 파일에 Redo 스레드의 공간을 만듦

  • 따라서MAXINSTANCES의 값을 초과하는 인스턴스 개수를 정의할 수 없음

  • MAXINSTANCES의 값을 변경하려면 컨트롤 파일을 재생성해야 함

  • MAXINSTANCES의 값을 변경하려면 동시에 MAX_INSTANCE_COUNT 파라미터 값도 같은 값으로 설정해야 함 (기본값: 8, 최솟값: 1, 최댓값: 1024)

MAXLOGGROUPS

  • 로그 그룹의 최댓값을 제한

  • 컨트롤 파일에 로그 그룹을 위한 공간을 확보하기 위해 필요한 값

  • MAXLOGGROUPS의 값을 변경하려면 컨트롤 파일을 재생성해야 함(기본값: 255, 최댓값: 255)

MAXLOGFILES

  • MAXLOGGROUPS과 같은 의미이며, 사용자의 편의를 위해 제공

  • MAXLOGGROUPS와 MAXLOGFILES 중 하나만 사용해야 함

MAXFBLOGFILES

  • 플래시백 로그 그룹의 최댓값을 제한

  • 컨트롤 파일에 플래시백 로그 그룹을 위한 공간을 확보하기 위해 필요한 값

  • MAXFBLOGFILES의 값을 변경하려면 컨트롤 파일을 재생성해야함 (기본값: 255, 최댓값: 255)

MAXSTANDBYLOGFILES

  • 스탠바이 로그 그룹의 최댓값을 제한

  • 컨트롤 파일에 스탠바이 로그 그룹을 위한 공간을 확보하기 위해 필요한 값

  • MAXSTANDBYLOGFILES의 값을 변경하려면 컨트롤 파일을 재생성해야 함 (기본값: 255, 최댓값: 255)

MAXLOGMEMBERS

  • 로그 그룹 내의 로그 파일의 최대 개수를 제한(기본값: 8, 최댓값: 8)

  • MAXLOGMEMBERS의 값을 변경하려면 컨트롤 파일을 재생성해야 함

MAXARCHIVELOG

  • 컨트롤 파일에 기록될 수 있는 최대 아카이브 로그의 개수를 지정

  • 해당 개수를 넘어가는 아카이브 로그 파일이 생성되면 가장 오래된 아카이브 로그의 기록부터 덮어씀(기본값: 500, 최댓값: 64000)

MAXBACKUPSET

  • 컨트롤 파일에 기록될 수 있는 최대 백업셋의 개수를 지정

  • MAXBACKUPSET의 값을 변경하려면 컨트롤 파일을 재생성해야 함 (기본값: 500, 최댓값: 5000)

MAXLOGHISTORY

  • 컨트롤 파일에 기록될 수 있는 로그 파일 스위치 내역의 최대 갯수를 지정

  • 이 이상으로 로그 파일 스위치가 발생되면 가장 오래된 기록부터 덮어씀(기본값: 500, 최댓값: 64000)

MAXFBMARKER

  • 컨트롤 파일에 기록될 수 있는 최대 플래시백 마커의 개수를 지정

  • 이 이상으로 플래시백 마커를 남길 때는 가장 오래된 기록부터 덮어 씀(기본값: 168, 최댓값: 10080)

MAXFBARCHIVELOG

  • 컨트롤 파일에 기록될 수 있는 최대 플래시백 아카이브 로그의 개수를 지정

  • 이 개수를 넘어가는 플래시백 아카이브 로그 파일이 생성되면 가장 오래된 플래시백 아카이브 로그의 기록부터 덮어 씀 (기본값: 500, 최댓값: 64000)

ARCHIVELOG

  • ARCHIVELOG 모드로 설정

  • 로그 그룹은 순환적으로 재사용됨

  • 로그 그룹이 한 번 사용되고 나서 재사용되기 전에 시스템에 의해 아카이브될 수 있음

NOARCHIVELOG

NOARCHIVELOG 모드로 설정

  • 예제

다음은 CREATE CONTROLFILE을 사용해 컨트롤 파일을 생성하는 예입니다.

hashtag

hashtag
CREATE DATABASE

데이터베이스를 생성합니다.

CREATE DATABASE의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

Tibero를 NOMOUNT 모드로 기동하면, SYS 사용자만 CREATE DATABASE 문을 실행할 수 있습니다.

  • 구성요소

- create_database

구성요소
설명

database_name

  • $TB_SID.tip 파일의 DB_NAME 파라미터 값과 같아야 하며 생략할 수 있음

  • $TB_SID.tip 파일에 지정된 컨트롤 파일이 이미 존재하면 에러가 발생

  • 지정하지 않으면, 기본값은 환경설정 파일의 TB_SID와 동일

create_database_clause

  • 새로운 데이터베이스를 생성할 때 사용

  • NOMOUNT 모드에서만 사용할 수 있음

  • create_database_clause

구성요소
설명

USER SYS IDENTIFIED BY

  • SYS 사용자의 패스워드를 설정하는 데 사용됨 (기본값: tibero)

  • 설정된 패스워드는 ALTER USER 문을 통해 변경할 수 있음

  • 자세한 내용은 “ALTER USER”를 참고

MAXDATAFILES

  • 데이터베이스에서 사용할 최대 데이터 파일의 개수를 제한

  • MAXDATAFILES에 지정된 값만큼 컨트롤 파일에 데이터 파일의 공간을 만듦

  • 따라서 MAXDATAFILES의 값을 초과하는 데이터 파일의 개수를 정의 할 수 없음

  • MAXDATAFILES의 값을 변경하려면 컨트롤 파일을 재생성해야 함

  • MAXDATAFILES의 값이 클수록 많은 메모리가 요구되므로, 이점을 고려해서 값을 설정해야 함 (기본값: 100, 최솟값: 10, 최댓값: 65533)

MAXINSTANCES

  • 데이터베이스에서 사용할 최대 인스턴스 개수를 제한

  • MAXINSTANCES에 지정된 값만큼 컨트롤 파일에 Redo 스레드의 공간을 만듦

  • 따라서 MAXINSTANCES의 값을 초과하는 인스턴스 개수를 정의할 수 없음

  • MAXINSTANCES의 값을 변경하려면 컨트롤 파일을 재생성해야 함

  • MAXINSTANCES의 값을 변경하려면 동시에 MAX_INSTANCE_COUNT 파라미터 값도 같은 값으로 설정해야 함 (기본값: 8, 최솟값: 1, 최댓값: 1024)

CHARACTER SET

데이터베이스에 디폴트로 사용할 문자 집합을 지정할 수 있음

지정할 수 있는 문자 집합은 다음과 같음 – ASCII: ASCII 7-bit 영어 – EUCKR: EUC 16-bit 한국어 – MSWIN949: MS Windows 코드 페이지 949 한국어 – UTF8: 24-bit 국제 표준 다국어 (기본값) – SJIS: Shift-JIS 16-bit 일본어 – JA16SJIS: MS Windows 코드 페이지 932 일본어 – JA16SJISTILDE: 전각물결문자를 포함하는 MS Windows 코드 페이지 932 일본어 – JA16EUC: EUC 24-bit 일본어 – JA16EUCTILDE: 전각물결문자를 포함하는 EUC 24-bit 일본어 – VN8VN3: VN3 8-bit 베트남어 – GBK: MS Windows 코드 페이지 936 중국어 – WE8MSWIN1252: MS Windows 코드 페이지 1252 서유럽어 – EL8MSWIN1253: MS Windows 코드 페이지 1253 그리스어 – AR8MSWIN1256: MS Windows 코드 페이지 1256 아랍어 – ZHT16HKSCS: HKSCS2001 홍콩어와 MS Windows 코드 페이지 950 중 국어 – WE8ISO8859P1: ISO8859-1 서유럽어 – EE8ISO8859P2: ISO8859-2 동유럽어 – AR8ISO8859P6: ISO8859-6 아랍어 – EL8ISO8859P7: ISO8859-7 그리스어 – WE8ISO8859P9: ISO8859-9 서유럽어(터키어) – WE8ISO8859P15: ISO8859-15 서유럽어 – CL8MSWIN1251: MS Windows 코드 페이지 1251 키릴문자(러시아어, 불 가리아어) – CL8KOI8R: KOI8-R 키릴문자(러시아어, 불가리아어) – CL8ISO8859P5: ISO8859-5 키릴문자(러시아어, 불가리아어) – EUCTW: EUC 중국어 번체 – GB18030: 중국 정부 표준 중국어 – IW8ISO8859P8: ISO 8859-8 라틴어, 히브리어 – RU8PC866: IBM-PC 코드 페이지 866 8-bit 키릴문자 (러시아어) – SJISTILDE: 전각물결문자를 포함하는 SHIFT-JIS 16-bit 일본어 – TH8TISASCII: 태국 산업 표준 620-2533-ASCII 8-bit 태국어 – UTF16: 16/32-bit 가변 길이 국제 표준 다국어 – ZHT16BIG5: BIG5 16-bit 중국어 – ZHT16MSWIN950: MS Windows 코드 페이지 950 중국어

NATIONAL CHARAC TER SET

  • NCHAR, NCLOB, NVARCHAR2로 정의된 컬럼을 저장할 때 사용할 국가별 문자 집합을 지정

  • 지정할 수 있는 문자 집합에는 UTF8, UTF16 등이 있음 – UTF16: 16-bit 국제 표준 다국어 (기본값)

DATAFILE

  • 시스템 테이블 스페이스의 데이터 파일을 정의

  • 하나 이상의 데이터 파일이 정의되어야 함

  • 지정하지 않으면 '$TB_HOME/database/$TB_SID/system001.dbf' 파일 하나가 테이블 스페이스에 추가

  • 'system001.dbf' 파일이 이미 존재하는 경우 'system002.dbf, system003.dbf, ...' 순으로 존재하지 않는 파일의 이름으로 생성됨($TB_HOME, $TB_SID 는 각각 환경변수 TB_HOME, TB_SID)

DEFAULT TA BLESPACE

  • 사용자의 디폴트 테이블 스페이스를 정의할 때 지정

  • 지정하지 않으면 일반 사용자도 SYSTEM 테이블 스페이스를 디폴트 테이블 스페이스로 사용

DEFAULT TEMPORARY

  • 디폴트 임시 테이블 스페이스를 정의

  • 지정하지 않으면 'TEMP'라는 이름의 테이블 스페이스가 생성되고, '$TB_HOME/database/$TB_SID/temp001.dbf' 파일이 추가

  • 'temp001.dbf' 파일이 이미 존재할 경우 'temp002.dbf, temp003.dbf, ...' 순으 로 존재하지 않는 파일의 이름으로 생성됨

UNDO TABLESPACE

  • Undo 테이블 스페이스를 정의

  • Undo 테이블 스페이스는 반드시 정의되 어야 하며 하나만 정의할 수 있음

  • 지정하지 않으면 'UNDO'라는 이름의 테이블 스페이스가 생성되고, '$TB_HOME/database/$TB_SID/undo001.dbf' 파일이 추가됨

  • 'undo001.dbf ' 파일이 이미 존재할 경우 'undo002.dbf, undo003.dbf, ...' 순으 로 존재하지 않는 파일의 이름으로 생성됨

– create_database_logging_clause

구성요소
설명

LOGFILE

  • 온라인 로그 파일을 지정

  • 온라인 로그 파일은 두 개 이상의 로그 그룹을 정의하고, 그룹별로 하나 이상 의 멤버를 지정해야 함

MAXLOGGROUPS

  • 로그 그룹의 최댓값을 제한

  • 컨트롤 파일의 로그 그룹을 위한 공간을 확보하기 위해 필요한 값

  • 해당 항목의 값을 변경하기 위해서는 컨트롤 파일을 재생성해야 함 (기본값: 255, 최댓값: 255) (LOGGROUP_CNTMAX_PER_DATABASE)

MAXLOGFILES

  • MAXLOGGROUPS와 같은 의미이며, 사용자의 편의를 위해 제공

  • MAXLOGGROUPS와 MAXLOGFILES 중 하나만 사용해야 함

MAXLOGMEMBERS

  • 로그 그룹 내의 로그 파일의 최대 개수를 제한

  • 해당 항목의 값을 변경하려면 컨트롤 파일을 재생성해야 함 (기본값: 8, 최댓값: 8) (LOGMEMBER_CNTMAX_PER_LGGGROUP)

ARCHIVELOG

  • ARCHIVELOG 모드로 설정

  • 로그 그룹은 순환적으로 재사용됨

  • 로그 그룹이 한 번 사용되고 나서 재사용되기 전에 시스템에 의해 아카이브될 수 있음

MAXARCHIVELOG

  • 컨트롤 파일에 기록될 수 있는 최대 아카이브 로그의 개수를 지정

  • 이 갯수를 넘어가는 아카이브 로그 파일이 생성되면 가장 오래된 아카이브 로그의 기록부터 덮어쓰게 됨(기본값: 500, 최댓값: 64000)

MAXBACKUPSET

  • 컨트롤 파일에 기록될 수 있는 최대 백업셋의 개수를 지정

  • MAXBACKUPSET의 값을 변경하려면 컨트롤 파일을 재생성해야 함 (기본값: 500, 최댓값: 5000)

MAXLOGHISTORY

  • 컨트롤 파일에 기록될 수 있는 로그 파일 스위치 내역의 최대 개수를 지정

  • 이 이상으로 로그 파일 스위치가 발생되면 가장 오래된 기록부터 덮어쓰게 됨

NOARCHIVELOG

NOARCHIVELOG 모드로 설정

– dfspec

구성요소
설명

filename

  • filename은 절대경로와 상대경로로 지정할 수 있음

  • 상대경로는 '$TB_HOME/database/$TB_SID/'로 지정

SIZE

  • byte 단위로 파일 크기를 정의

  • M(megabyte), K(kilobyte), G(gigabyte) 등의 기호를 사용하여 보다 큰 크기의 파일을 쉽게 정의할 수 있음

REUSE

  • 기존의 파일이 있을 때 덮어쓸지의 여부를 지정

  • REUSE가 없으면 같은 이름의 파일이 존재하면 에러가 발생

autoextend_clause

저장할 데이터가 파일 크기를 초과할 경우 파일 크기의 확장 여부를 결정

- tablespace_spec_clause

구성요소
설명

tablespace_name

테이블 스페이스의 이름을 지정

dfspec

  • 파일의 이름, 파일의 크기 등과 관련된 여러 가지 설정을 할 수 있음

  • 자세한 내용은 'dfspec' 항목 설명을 참고

extspec_clause

테이블 스페이스의 익스텐트가 어떻게 관리될 것인지 명시

- autoextend_clause

구성요소
설명

AUTOEXTEND OFF

  • 저장할 데이터가 파일 크기를 초과할 경우 더는 저장하지 못하도록 함

  • 이러한 경우 ALTER DATABASE의 RESIZE를 통해 수동으로 파일 크기를 늘려주거나 해당 테이블 스페이스에 파일을 추가하여 해결할 수 있음

  • 테이블 스페이스에 파일을 추가하는 방법은 “7.2. ALTER DATABASE”를 참고

AUTOEXTEND ON

저장할 데이터가 파일 크기를 초과할 경우 자동으로 파일을 늘려줌

NEXT

  • 파일의 크기를 확장할 때 늘어나는 크기를 지정할 수 있음

  • 너무 작은 값을 지정하면 파일 확장이 빈번히 일어나고, 너무 큰 값을 지정하면 저장 공간을 낭비할 수 있으므로 이를 주의

MAXSIZE

파일 크기의 최댓값을 지정할 수 있음

- log_member_clause

구성요소
설명

GROUP

  • 로그 그룹의 번호를 지정할 수 있음

  • 지정하지 않으면 0부터 차례대로 지정됨

REUSE

기존에 존재하는 파일에 덮어쓰고자 할 경우에 사용

  • 예제

다음은 CREATE DATABASE를 사용해 데이터베이스를 생성하는 예입니다.

hashtag

hashtag
CREATE DATABASE LINK

데이터베이스 링크를 생성합니다. 데이터베이스 링크는 다른 데이터베이스의 객체에 접근할 수 있도록 해 준다. 객체의 이름 뒤에 '@ 데이터베이스 링크 이름'을 붙여줌으로써 가능합니다.

접근할 데이터베이스는 반드시 Tibero일 필요는 없습니다. 기능의 제약이 있기는 하지만, 다른 종류의 데이터 베이스의 객체에 접근할 수 있습니다. 데이터베이스를 생성하고 나면, 테이블, 뷰 등과 같은 연결된 데이터베 이스의 객체에 접근하여 DML 문을 수행할 수 있습니다.

circle-info

참고

데이터베이스 링크에 대한 자세한 내용은 "Tibero 관리자 안내서"를 참고합니다.

CREATE DATABASE LINK의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

    • 사용자가 자신만 사용할 수 있는 데이터베이스 링크를 생성하기 위해서는 CREATE DATABASE LINK시스템 특권이 있어야 합니다.

    • 공유 데이터베이스 링크를 생성하기 위해서는 CREATE PUBLIC DATABASE LINK 시스템 특권이 있어야 합니다.

    • 원격 데이터베이스 링크를 생성하기 위해서는 CREATE SESSION 시스템 특권이 있어야 합니다.

  • 구성요소

구성요소
설명

PUBLIC

  • 모든 사용자가 사용할 수 있는 공유 데이터베이스 링크를 생성하기 위해 사용

  • 생략하면 생성한 사용자만이 사용할 수 있는 데이터베이스 링크가 생성됨

dblink_name

  • 생성할 데이터베이스 링크의 이름

  • 데이터베이스 링크의 이름을 지정할 때 스키마를 지정할 수 없음

  • 즉, 다른 사 용자의 스키마에 데이터베이스 링크를 생성할 수 없음

  • 데이터베이스 링크에 서는 점(.) 기호도 이름에 포함되는 문자로 인식

  • 공유 데이터베이스 링크가 아니면 생성한 사용자 이외의 다른 사용자는 그 데이터베이스 링크를 사용할 수 없음

  • 여러 사용자가 데이터베이스 링크를 사용하기 위해서는 반드시 공유 데이터베이스 링크로 생성해야 함

CONNECT TO us er_name IDENTIFIED BY password

  • 데이터베이스 링크를 통해 원격 데이터베이스에 접속할 때 필요한 사용자의 이름과 패스워드를 설정

  • CONNECT TO를 생략하면 현재 접속한 사용 자의 이름과 패스워드로 설정됨

  • 원격 데이터베이스에 접속하기 위해서는 user_name과 password에 지정한 사용자의 이름과 패스워드, 그리고 원격 데이터베이스에 사용자가 생성되어 있어야 함

  • 이때, 패스워드는 기호(작은따옴표) 사이에 패스워드가 입력된 경우에만 유효

  • 예를 들어 아래 예제에서 "tmax"로 패스워드가 입력된 경우에는 데이터베이스 링크 생성에 실패하게 됨

USING connect_string

  • 원격 데이터베이스의 서비스의 이름을 리터럴 형태로 지정

  • 서비스는 tbdsn.tbr 파일에 지정해야 함

  • 이 파일에는 서비스 이름, HOST, 포트 번호, 데이터베이스의 이름 등을 설정할 수 있음

  • tbdsn.tbr 파일에 지정된 서비스의 이름을 connect_string과 동일하게 입력해야 정상으로 연결할 수 있음

USING connect_string2

  • tbdsn.tbr 파일을 통하지 않고 직접 connection에 필요한 정보를 string형태로 USING 절에 기입하여 데이터베이스 링크를 생성할 수 있음

  • connect_string2에는 HOST, 포트 번호, 데이터베이스 이름 등을 tbdsn .tbr에 적는 형식으로 구성

  • 이 경우 connect_string의 최대 길이는 128byte로 제한됨

  • 예제

다음은 CREATE DATABASE LINK를 사용해 데이터베이스 링크를 생성하는 예입니다.

hashtag

hashtag
CREATE DIRECTORY

디렉터리 객체를 생성합니다. 디렉터리를 제거하기 위해서는 “DROP DIRECTORY”의 내용을 참고한 다.

CREATE DIRECTORY의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

    • 디렉터리를 생성하기 위해서는 CREATE ANY DIRECTORY 시스템 특권이 있어야 합니다.

    • 디렉터리를 생성하면 그 디렉터리에 읽기와 쓰기 권한이 자동으로 부여되며, 다른 사용자 또는 역할 에 권한을 부여할 수 있습니다.

  • 구성요소

구성요소
설명

OR REPLACE

  • 생성할 디렉터리의 이름이 기존 디렉터리와 동일하면 기존 디렉터리를 제거하고 새로 만듦

  • 기존의 디렉터리를 삭제한 뒤 다시 생성하는 것과의 차이는 대상 디렉터리에 관련된 기존의 특권과 참조가 그대로 유지된다는 점

dir_name

생성할 디렉터리 객체의 이름

AS dir_path_string

  • 디렉터리 객체가 가리키는 디렉터리 경로를 지정

  • 지정한 디렉터리 경로의 존재 여부나 접근 권한에 대한 검사는 하지 않음

  • 잘못된 경로를 지정하면 외부 테이블 등에서 이 디렉터리를 접근하면 에러가 발생

  • 디렉터리 경로는 문자열 리터럴로 표현하며, 대소문자를 구분

  • 예제

다음은 CREATE DIRECTORY를 사용해 '/tmp' 경로를 가리키는 tmp라는 디렉터리 객체를 생성하는 예입니다.

hashtag

hashtag
CREATE DISKSPACE

디스크스페이스를 생성합니다.

CREATE DISKSPACE의 세부 내용은 다음과 같습니다.

  • 문법

  • 구성요소

– create_diskspace

구성요소
설명

diskspace_name

생성할 디스크스페이스의 이름을 명시

REDUNDANCY

  • 디스크스페이스에 저장되는 사용자 파일의 중복 레벨을 지정

  • 중복 레벨 이 높을수록 데이터 유실 위험이 줄어드는 대신 디스크 공간 사용과 디스크 쓰기에 대한 부하가 증가

  • 다음 3가지 중복 레벨 중 하나를 사용할 수 있음 – HIGH: 디스크스페이스의 모든 파일을 서로 다른 세 개의 failgroup에 중복 해서 저장. 세 개 이상의 failgroup이 있는 경우에만 지정할 수 있으며, 최대 두 개의 failgroup에 장애가 발생하더라도 정상적인 서비스가 가능. – NORMAL: 디스크스페이스의 모든 파일을 서로 다른 두 개의 failgroup에 중복해서 저장 두 개 이상의 failgroup이 있는 경우에만 지정할 수 있으며, 하나의 failgroup에 장애가 발생하더라도 정상적인 서비스가 가능. 중복 레벨이 지정되지 않은 경우의 기본값. – EXTERNAL: 중복 저장 기능을 사용하지 않음. 디스크 자체의 중복 저장 기능을 사용하거나, 디스크 장애로 인한 데이터 유실을 감수할 수 있는 경우 선택.

FAILGROUP fail group_name

  • 디스크가 속할 failgroup 이름을 명시

  • 디스크스페이스의 중복 레벨이 NORMAL 또는 HIGH인 경우에만 유효하며, 알파벳과 숫자 등으로 최대 48자를 사용할 수 있음

  • 명시하지 않은 경우에는 모든 디스크가 각각 하나의 failgroup으로 구성되며 디스크 이름이 failgroup 이름으로 사용됨

DISK quali fied_disk_clause

디스크스페이스를 구성할 디스크를 정의

ATTRIBUTE

  • 디스크스페이스의 속성을 지정

  • 지정할 수 있는 속성은 다음과 같음 – AU_SIZE: 디스크스페이스의 공간 할당 단위를 byte로 지정(기본값:1MB) – SECTOR_SIZE: 디스크스페이스를 구성하는 디스크들의 섹터 사이즈를 지정(기본값: 512)

– qualified_disk_clause

구성요소
설명

search_string

  • 디스크스페이스를 구성할 디스크의 경로를 명시

  • 와일드카드를 사용해 여러 디스크를 나타낼 수 있으며, TAS_DISKSTRING 초기화 파라미터로 찾을 수 있는 경로이어야 함

NAME disk_name

  • search_string으로 찾은 디스크의 이름을 명시

  • search_string으로 찾은 디스크가 한 개인 경우에만 지정할 수 있으며, 알파벳과 숫자 등으로 최대 48자를 사용할 수 있음

  • 디스크의 이름은 TAS 내부에 서만 사용되며 디스크 경로와는 무관

  • 명시하지 않은 경우 임의로 생성된 이름이 사용됨

SIZE

  • search_string으로 찾은 디스크의 크기를 byte 단위로 명시

  • search_string 으로 찾은 디스크가 여러 개인 경우 모든 디스크가 같은 크기로 지정

  • 명시하지 않은 경우 TAS에서 파악한 실제 디스크의 크기가 지정됨

  • TAS 에서 실제 디스크를 크기를 알 수 없는 경우 오류가 발생하며, 이 때는 반드시 디스크 크기를 명시해 주어야 함

FORCE

  • search_string으로 찾은 디스크가 이미 다른 디스크스페이스에 사용 중이더 라도 이를 무시하고 새로운 디스크스페이스 구성에 사용

  • 기존 디스크스 페이스를 파기하는 경우에 명시

NOFORCE

  • search_string으로 찾은 디스크가 이미 다른 디스크스페이스에 사용 중인 경우 오류가 발생

  • FORCE 또는 NOFORCE가 명시되지 않은 경우의 기본 동작

  • 예제

다음은 CREATE DISKSPACE를 사용해 중복 저장을 사용하지 않는 디스크스페이스를 생성하는 예입니다.

다음은 CREATE DISKSPACE를 사용해 세 개의 failgroup으로 구성된 디스크스페이스를 생성하는 예입니다.

hashtag

hashtag
CREATE FUNCTION

사용자 함수(User Function)를 새로 정의하거나 기존의 함수를 대체합니다. 사용자 함수는 반환 값이 있는 tbPSM 프로그램이며, Tibero 서버에 저장되고 실행됩니다. 사용자 함수가 사용자 프러시저(User procedure) 와 다른 점은 반환 값이 있으며, 질의 문장 또는 DML 문장에 포함될 수 있습니다는 것입니다.

CREATE FUNCTION의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

    • 사용자가 자신의 스키마에 함수를 생성하기 위해서는 CREATE PROCEDURE 시스템 특권을 부여받 아야 합니다.

    • 다른 사용자가 소유한 스키마에 함수를 생성하기 위해서는 CREATE ANY PROCEDURE 시스템 특 권을 부여받아야 하고, 변경하고자 하면 ALTER ANY PROCEDURE 시스템 특권을 부여받아야 합니다.

  • 구성요소

- create_function

구성요소
설명

OR REPLACE

  • 이미 존재하는 함수를 다시 정의하고자 할 때 사용

  • OR REPLACE 절이 포함되면 해당 함수를 재컴파일

  • 함수를 제거하고 다시 생성하는 것의 차이는 OR REPLACE 절을 이용 하면 해당 함수에 기존의 특권이 그대로 유지된다는 점

qualified_obj_name

함수의 스키마와 이름을 지정

argument

  • 함수의 파라미터

  • 함수의 파라미터는 0개 이상이 될 수 있음

  • 파라미터가 0개이면 파라미터를 감싸는 괄호를 생략

IN

  • 함수의 파라미터의 전달 방향에 따른 구분

  • IN 파라미터는 외부로부터 값을 입력받음

  • 디폴트는 IN 파라미터

  • 함수에서는 현재 트랜잭션에 COMMIT, ROLLBACK, SAVEPOINT를 수 행할 수 없고 DDL 문장도 실행할 수 없음

  • 또한, 현재 액세스 중인 테이블에도 갱신을 수행할 수 없음

OUT

  • 함수의 파라미터의 전달 방향에 따른 구분

  • OUT 파라미터는 함수 내부로부터 값을 출력

  • DML 문장에 포함된 함수는 OUT 파라미터를 가질 수 없음

  • DML 문장 에 포함된 함수로부터 직접 또는 간접적으로 호출되는 함수는 OUT 또 는 IN OUT 파라미터를 가질 수 있으나 나머지는 불가능

IN OUT

  • 함수의 파라미터의 전달 방향에 따른 구분

  • IN OUT 파라미터는 입력과 출력 모두에 사용됨

  • DML 문장에 포함된 함수는 IN OUT 파라미터를 가질 수 없음

NOCOPY

  • 파라미터의 값을 가리키는 포인터(Pointer)를 전달

  • 파라미터의 값을 복사하지 않기 때문에 전달 속도가 빠름

datatype

  • 함수 파라미터 또는 반환 값의 데이터 타입

  • 함수의 파라미터 또는 반환 값의 데이터 타입은 tbPSM에서 지원하는 모든 데이터 타입이 가능

  • 반환 값의 데이터 타입을 선언할 때 문자 열의 길이, 숫자의 정밀도와 스케일은 지정할 수 없음

RETURN

함수의 반환 값의 데이터 타입을 설정

invoker_right_clause

  • 사용자 함수는 호출자 권한(Invoker-rights) 함수 또는 정의자 권한(Defin er-rights) 함수로 구분할 수 있음

  • 이는 함수를 실행할 때에 어떤 사용자의 특권을 이용하여 실행할 것인 지, 액세스하고자 하는 테이블 등의 객체는 어떤 스키마에서 찾을 것인 지 등을 결정

  • 디폴트는 정의자 권한 함수

deterministic_clause

함수를 캐싱 가능 함수로 선언

parallel_enable_clause

함수를 병렬 실행 가능합니다고 명시

result_cache_clause

함수 결과를 서버 결과 캐시에 저장함을 나타냄

aggregate_clause

함수를 집계 함수로 식별

pipelined_clause

함수를 파이프라인 함수로 선언

IS

  • IS나 AS는 기호에 맞게 선택해서 사용하고 둘의 차이는 없음

  • IS 다음에는 함수의 본문이 옴

AS

  • IS와 동일

  • AS 다음에는 함수의 본문이 옴

psm_source

  • PSM 소스 코드가 오는 부분

  • 자세한 내용은 "Tibero tbPSM 안내서"를 참고

call_spec

  • 외부 함수를 호출하기 위한 명세를 지정

  • 자세한 내용은 "Tibero tbPSM 안내서"를 참고

  • invoker_right_clause

구성요소
설명

AUTHID CURRENT_USER

  • 사용자 함수를 호출자 권한 함수로 선언

  • 생략하면 정의자 권한 함수로 선언

  • 호출자 권한 함수로 선언하면, 현재 사용자의 특권을 이용하며 현재 사용자의 스키마에서 액세스할 객체를 찾음

  • 따라서, 함수를 호출하는 사용자가 달라지면 가능한 작업의 범위와 액세스하는 스키마 객체도 달라짐

  • 이러한 함수는 여러 사용자가 공통으로 동일한 작업을 수행하 고자 할 때에 유용함

AUTHID DEFINER

  • 사용자 함수를 정의자 권한 함수로 선언

  • 디폴트이므로 생략하면 정의자 권한 함수로 선언됨

  • 정의자 권한 함수로 선언하면, 함수를 정의한 사용자의 특권을 이용하고 그 사용자의 스키마에서 액세스할 객체를 찾음

  • 따라서, 호출자에 관계없이 작업의 범위와 액세스하는 스키마 객체가 항상 일정

  • 이러한 함수는 데이터 사전 등의 시스템 데이터의 일부를 일반 사용자가 액세스할 수 있을 때 유용

  • deterministic_clause

구성요소
설명

DETERMINISTIC

  • 사용자 함수를 결정적 함수로 선언하고, 함수의 반환 값을 강제로 캐싱 하여서 반환

  • 생략하면 컴파일 시 캐싱 가능 여부를 판단하여 함수를 생성

  • parallel_enable_clause

구성요소
설명

PARALLEL_ENABLE

사용자 함수가 병렬 실행될 수 있음을 나타냄

  • result_cache_clause

구성요소
설명

RESULT_CACHE

사용자 함수의 결과를 공유 메모리의 캐쉬에 저장

RELIES_ON

  • 함수 결과가 의존하는 데이터 소스들을 지정

  • 더이상 사용되지 않는 기능

  • 결과 캐시 기능이 실행되는 동안 쿼리 되는 모든 데이터 소스들을 감지하므로, 적는 것이 무의미

data_source_name

  • 데이터 소스의 이름

  • 스키마 이름을 포함해도 됨

  • aggregate_clause

구성요소
설명

AGGREGATE USING

사용자 함수를 집계 함수로 선언

object_type_name

  • 집계 함수가 참조하는 객체 타입의 이름을 명시

  • 객체 타입은 쿼리 수행기의 AGGREGATION 동작을 포함하는 TUDIAG GREGATEINITIALIZE, TUDIAGGREGATEITERATE, TUDIAGGRE GATETERMINATE, TUDIAGGREGATEMERGE(선택가능)이 포함되어야 함

  • "객체 타입의 이름" 또는 "스키마명.객체 타입"의 이름으로 쓸 수 있음

  • pipelined_clause

구성요소
설명

PIPELINED

사용자 함수를 파이프라인 함수로 선언

  • 예제

다음은 CREATE FUNCTION을 사용해 사용자 함수를 새로 정의하는 예입니다.

hashtag

hashtag
CREATE INDEX

인덱스를 생성합니다. 기반 테이블의 하나 이상의 컬럼에 인덱스를 생성할 수 있습니다.

CREATE INDEX의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

다음 중 하나를 만족해야 CREATE INDEX 문을 실행할 수 있습니다.

  • 기반 테이블이 사용자 자신의 스키마에 포함되어 있습니다.

  • 기반 테이블에 대한 INDEX 스키마 객체 특권이 있습니다.

  • CREATE ANY INDEX 시스템 특권이 있습니다.

  • 구성요소

- create_index

구성요소
설명

UNIQUE

  • 지정되면 유일 인덱스를 생성

  • 유일 인덱스에는 중복된 키 값이 저장 될 수 없음

BITMAP

지정되면 비트맵 인덱스를 생성

not_exist

IF NOT EXISTS 해당 옵션을 명시하면 – 동일한 이름의 OBJECT가 이미 존재하는 경우에도 에러 로그를 발생 시키지 않고 성공 메시지를 반환 – OBJECT가 존재하지 않는 경우에는 기존 CREATE 문과 동일하게 동 작

schema

  • 인덱스를 생성할 스키마를 명시

  • 생략하면 현재 사용자의 스키마로 인식됨

index_name

생성할 인덱스의 이름을 명시

ON table_index_clause

인덱스를 생성할 테이블의 구체적인 내용을 명시

UNUSABLE

  • 인덱스를 사용 불가능한 상태로 생성

  • 이 인덱스를 사용하기 위해서는 ALTER INDEX의 REBUILD를 통해 재생성해야 함

– table_index_clause

구성요소
설명

schema

  • 인덱스를 생성할 테이블이 속해 있는 스키마를 명시

  • 생략하면 현재 사용자의 스키마로 인식됨

table_name

인덱스를 생성할 테이블의 이름을 명시

column_expr

  • 인덱스 키로 사용될 컬럼 이름 또는 표현식을 명시

  • 인덱스 키로는 LONG, LONG RAW 타입, 대용량 객체형 등이 올 수 없음

  • user function 등의 expression과 그 결과 값도 동일한 제한을 가짐

  • 같은 키를 갖는 인덱스가 데이터베이스에 이미 존재합니다면 똑같은 인덱 스를 생성하는 것이 제한됨

  • 이는 중복된 인덱스 사용으로 불필요하게 효율이 떨어지는 것을 막기 위함입니다. 따라서 같은 인덱스를 만들기보다 는 이미 만들어진 인덱스에 대한 권한을 얻어서 사용하는 것이 좋음

  • 인덱스 키 표현식에서 사용자 정의 함수를 사용하는 경우에는 함수가 반드시 DETERMINISTIC으로 선언되어야 함

  • 사용한 함수가 변경되거나 삭제되면 해당 인덱스는 사용할 수 없는 상태가 됨

  • 또한, 인덱스 키 표 현식에서 사용하는 함수는 항상 동일한 결과 값을 가져야 함

  • 예를 들어 SYSDATE 등과 같이 결과 값이 변하는 함수는 사용할 수 없음

ASC

컬럼 값의 정렬 순서를 오름차순으로 지정 (기본값)

DESC

  • 컬럼 값의 정렬 순서를 내림차순으로 지정

  • 내림차순 정렬순서는 다음과 같은 경우에 사용 – 복합 키로 사용하는 경우: 컬럼 A에 대해서는 오름차순으로 하되, 컬럼 A가 동일한 값을 가질 때 B를 내림차순으로 정렬하고 싶은 경우(A, B DESC)를 지정하면 됨. – 키가 삽입되는 순서가 내림차순일 경우: Tibero의 인덱스는 주로 오름 차순으로 삽입되는 것에 최적화되어 설계되어 있음. 따라서 키가 주로 내림차순으로 삽입되는 경우 내림차순으로 정렬해야 인덱스의 효율이 더 좋아짐.

index_properties

인덱스의 구체적인 속성을 지정

tde_range

암호화 테이블의 인덱스를 이용하여 Range 스캔을 할 것인지 여부를 설정

  • index_properties

구성요소
설명

index_attributes

인덱스의 물리적인 속성을 지정

index_local_partition_clause

  • 로컬 파티션 인덱스를 생성

  • 테이블의 파티션과 동일한 개수로 생성되며, 테이블 파티션이 변경되면 인덱스 파티션도 자동으로 같이 변경됨

index_global_partition_clause

  • 글로벌 파티션 인덱스를 생성

  • 테이블의 파티션 여부와 상관없이 인덱스 고유의 파티셔닝을 지정하여 인덱스를 생성

  • index_attributes

구성요소
설명

sgmt_attr

sgmt_attr 관련 문법은 “Sgmt_attr”을 참고합니다.

index_compression

인덱스의 압축 여부를 지정

TABLESPACE (DEFAULT)

  • 인덱스를 생성할 테이블 스페이스를 지정

  • 생략하거나 DEFAULT로 설정하면 기반 테이블이 있는 테이블 스페이스에 인덱스를 생성

REVERSE

  • ROWID를 제외한 인덱스 블록의 바이트 순서를 역으로 저장

  • 비슷한 키 값이 집중된 경우 이를 분산하고 싶을 때 사용

ONLINE

인덱스의 생성 도중 DML을 허용하고 싶을 때 사용

INVISIBLE

  • 인덱스의 상태 옵션

  • 인덱스의 VISIBLE과 INVISIBLE 여부는 OPTI MIZER가 해당 인덱스를 고려하는지 여부와 관련이 있

  • 음INVISIBLE 상태인 인덱스는 DML 과정에 일반 인덱스처럼 형태를 계속 유지

  • 하지만 Optimizer에서 고려할 대상으로 여기지 않음

COMPUTE STATISTICS

  • 인덱스 생성 직후에 인덱스 통계 정보를 수집하고자 할 때 사용

  • B-Tree INDEX 와 IOT Secondary INDEX일 때만 사용할 수 있음

  • index_local_partition_clause

구성요소
설명

on_range_partitioned_table

  • RANGE 파티션 테이블에 대한 로컬 파티션 인덱스를 생성할 때 사용

  • PARTITION 절을 사용할 경우 PARTITION 절의 개수는 테이블의 파티션 개수와 동일해야 하며, 맞지 않을 경우 에러가 발생

  • 자세한 내용은 “Sgmt_attr”을 참고

on_list_partitioned_table

  • LIST 파티션 테이블에 대한 로컬 파티션 인덱스를 생성할 때 사용

  • 자세한 내용은 on_range_partitioned_table을 참고

on_hash_partitioned_table

  • HASH 파티션 테이블에 대한 로컬 파티션 인덱스를 생성할 때 사용

  • 자세한 내용은 on_hash_partitioned_table을 참고

on_composite_partitioned_table

  • 복합 파티션 테이블에 대한 로컬 파티션 인덱스를 생성할 때 사용

  • 자세한 내용은 on_range_partitioned_table을 참고

  • on_range_partitioned_table

구성요소
설명

partition_name

인덱스 파티션의 이름을 지정할 때 사용하며, 지정하지 않으면 시스템이 자동으로 생성

sgmt_attr

  • sgmt_attr는 인덱스 파티션으로 사용될 세그먼트의 속성을 지정

  • sgmt_attr 관련 문법은 “Sgmt_attr”을 참고

  • on_list_partitioned_table

구성요소
설명

partition_name

인덱스 파티션의 이름을 지정할 때 사용하며, 지정하지 않으면 시스템이 자동으로 생성

sgmt_attr

  • sgmt_attr는 인덱스 파티션으로 사용될 세그먼트의 속성을 지정

  • sgmt_attr 관련 문법은 “Sgmt_attr”을 참고

  • on_hash_partitioned_table

구성요소
설명

STORE IN

  • 각 파티션이 위치할 테이블 스페이스를 지정

  • 테이블 스페이스를 지정한 개수가 파티션의 개수와 일치할 필요는 없으며, 개수가 서로 다를 경우 라운드 로빈(round-robin) 방식으로 테이블 스 페이스가 차례대로 지정

tablespace

테이블 스페이스를 명시

partition_name

인덱스 파티션의 이름을 지정할 때 사용하며, 지정하지 않으면 시스템이 자동으로 생성

sgmt_attr

  • sgmt_attr는 인덱스 파티션으로 사용될 세그먼트의 속성을 지정

  • sgmt_attr 관련 문법은 “Sgmt_attr”을 참고

  • on_composite_partitioned_table

구성요소
설명

partition_name

인덱스 파티션의 이름을 지정할 때 사용하며, 지정하지 않으면 시스템이 자동으로 생성

sgmt_attr

  • sgmt_attr는 인덱스 파티션으로 사용될 세그먼트의 속성을 지정

  • sgmt_attr 관련 문법은 “Sgmt_attr”을 참고

index_subpartition_clause

  • 각 서브 파티션의 세부적인 설정을 지정

  • 단, STORE IN은 서브 파티셔닝 방법이 HASH일 경우에만 사용할 수 있음

  • 서브 파티션이라는 점 외에 다른 문법은 기본 파티셔닝과 동일

  • 자세한 내용은 on_range_partitioned_table을 참고

  • index_subpartition_clause

구성요소
설명

STORE IN

  • 서브 파티셔닝 방법이 HASH일 경우에만 사용할 수 있음

  • STORE IN 절은 각 파티션이 위치할 테이블 스페이스를 지정

  • 테이블 스페이스를 지정한 개수가 파티션의 개수와 일치할 필요는 없으며, 개수가 서로 다를 경우 라운드 로빈 방식으로 테이블 스페이스가 차례대로 지정

tablespace

테이블 스페이스를 명시

subpartition_name

인덱스 서브 파티션의 이름을 지정할 때 사용하며, 지정하지 않으면 시스템이 자동으로 생성

sgmt_attr

  • 인덱스 서브 파티션으로 사용될 세그먼트의 속성을 지정

  • sgmt_attr 관련 문법은 “Sgmt_attr”을 참고

  • index_global_partition_clause

구성요소
설명

RANGE

서브 파티션의 파티셔닝 방법을 RANGE 파티션으로 설정

HASH

서브 파티션의 파티셔닝 방법을 HASH 파티션으로 설정

column

  • 인덱스 키 컬럼으로 사용된 컬럼 중에서 파티션의 기준이 되는 컬럼을 지정

  • 단, 파티션 키 컬럼이 인덱스 키 컬럼의 앞부분을 반드시 포함해야 함

  • 즉, 인덱스의 키가 (a, b, c)라면 (a), (a, b), (a, b, c)를 파티션 키 컬럼으로 지정할 수 있음

  • 인덱스 키 컬럼의 앞부분을 포함하지 않도록 파티션 키를 정하면 에러가 발생

  • 인덱스를 어떤 기준으로 파티션할지는 테이블이 어떻게 파티션되어 있는 지와는 전혀 관계가 없음

  • 테이블이 파티션되는 방식과 인덱스가 파티션 되는 방식이 다를 수 있음

  • 또한, 테이블이 파티션되어 있지 않더라도 인덱스는 파티션할 수 있고, 반대로 테이블이 파티션되어 있더라도 인덱스는 파티션되지 않을 수도 있음

index_partitioning_clause

RANGE 파티션 인덱스의 세부적인 속성을 지정

hash_partition_desc

HASH 파티션의 세부적인 속성을 지정

hash_partitions_by_quantity

HASH 파티션을 파티션 개수와 테이블 스페이스만 지정함으로써 간단하게 생성할 수 있도록 해 주는 문법

  • index_partitioning_clause

구성요소
설명

partition_name

인덱스 파티션의 이름을 지정할 때 사용하며, 지정하지 않으면 시스템이 자동으로 생성

value

  • 파티션을 나눌 기준 값을 지정

  • value로 사용된 값보다 작은 값이 해당 파티션에 포함

  • MAXVALUE 로 지정하면 다른 파티션에 속하지 않는 모든 값이 해당 파티션으로 포함

  • column에서 사용된 컬럼 수와 값의 개수가 같아야 함

sgmt_attr

  • 인덱스 파티션으로 사용될 세그먼트의 속성을 지정

  • sgmt_attr 관련 문법은 “Sgmt_attr”을 참고

  • index_compression

구성요소
설명

COMPRESS unsigned_integer

  • 인덱스를 압축

  • 인덱스 키 컬럼의 상위 unsigned integer 개를 prefix key로 하여 index leaf block에 대해 중복되는 부분을 압축

  • unsigned integer의 default 값은 UNIQUE INDEX일 경우 인덱스 키 컬럼의 - 1, 아닐 경우 인덱스 키 컬럼의 값

COMPRESS ADVANCED LOW

아직 지원하지 않는 기능

NOCOMPRESS

인덱스를 압축하지 않

  • 예제

– create_index

다음은 UNUSABLE을 명시해 인덱스를 사용 불가능한 상태로 생성하는 예입니다.

– table_index_clause

다음은 column_expr을 명시해 인덱스를 생성하는 예입니다.

다음은 column_expr에 명시한 인덱스 키로 LONG 타입, LONG RAW 타입, 대용량 객체형 데이터 타입을 사용한 경우 에러가 발생하는 예입니다.

다음은 column_expr에 명시한 인덱스 키와 같은 키를 갖는 인덱스가 이미 존재할 경우 에러가 발생 하는 예입니다.

다음은 column_expr에 사용자 정의 함수를 사용할 때 사용자 정의 함수가 DETERMINISTIC으로 선 언되지 않았을 경우 에러가 발생하는 예입니다.

위의 예에서 SYSDATE 함수는 결과 값이 항상 변하기 때문에 사용할 수 없습니다.

다음은 UNIQUE를 명시하여 유일 인덱스를 생성하는 예입니다.

다음은 DESC를 명시하여 인덱스를 내림차순으로 생성하는 예입니다.

  • index_attributes

다음은 TABLESPACE를 명시하여 인덱스를 생성할 테이블 스페이스를 지정하는 예입니다.

– index_local_partition_clause

다음은 index_local_partition_clause를 명시하여 로컬 파티션 인덱스를 생성하는 예입니다.

다음은 index_local_partition_clause를 명시하여 로컬 파티션 인덱스를 생성하는 예입니다.

– index_global_partition_clause

다음은 index_global_partition_clause를 명시하여 글로벌 파티션 인덱스를 생성하는 예입니다.

다음은 index_global_partition_clause의 구성요소인 column 부분을 명시할 때 파티션 키 컬럼을 잘못 지정했을 경우 에러가 발생하는 예입니다.

다음은 index_global_partition_clause의 구성요소인 column 부분을 명시할 때 DESC로 지정된 인 덱스 키 컬럼을 파티션 키로 지정할 경우 에러가 발생하는 예입니다.

다음은 index_global_partition_clause의 구성요소인 value 부분을 명시할 때 값의 수가 컬럼의 개 수와 맞지 않거나 값이 정렬되지 않은 경우 에러가 발생하는 예입니다.

다음은 index_global_partition_clause의 구성요소인 value 부분을 명시할 때 컬럼 타입이 맞지 않 을 경우 에러가 발생하는 예입니다.

다음은 index_global_partition_clause의 구성요소인 value 부분을 명시할 때 MAXVALUE를 지정 하지 않을 경우 에러가 발생하는 예입니다.

– index_compression

다음은 index_compression를 명시하여 compressed 인덱스를 생성하는 예입니다.

다음은 index_compression의 구성요소인 unsigned_integer 부분을 명시할 때 잘못된 prefix length값을 입력할 경우 에러가 발생하는 예입니다.

다음은 index_compression에서 일반 인덱스, UNIQUE 인덱스 이외의 인덱스를 압축하려 할 때 에 러가 발생하는 예입니다.

hashtag

hashtag
CREATE MATERIALIZED VIEW

실체화 뷰를 생성하고 실체화 뷰의 속성을 지정합니다.

CREATE MATERIALIZED VIEW의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

사용자 자신이 소유한 스키마에 실체화 뷰를 생성 조건

  • CREATE MATERIALIZED VIEW 시스템 특권과 CREATE TABLE 또는 CREATE ANY TABLE 시스템 특권이 있어야 합니다.

  • 실체화 뷰가 참조하는 테이블 중 사용자 소유가 아닌 테이블에 대한 SELECT 객체 시스템 특권 또 는 SELECT ANY TABLE 시스템 특권이 있어야 합니다.

다른 사용자가 소유한 스키마에 실체화 뷰를 생성 조건

  • CREATE ANY MATERIALIZED VIEW 시스템 특권과 CREATE TABLE 시스템 특권이 있어야 한 다.

  • 실체화 뷰가 참조하는 테이블 중 해당 스키마를 소유한 사용자가 소유하지 않은 테이블에 대한 SELECT 객체 시스템 특권 또는 SELECT ANY TABLE 시스템 특권이 있어야 합니다.

  • 구성요소

- create_materialized_view

구성요소
설명

schema

  • 생성할 실체화 뷰의 스키마를 명시

  • 생략하면 현재 사용자의 스키마로 인식됨

mview_name

생성할 실체화 뷰의 이름을 명시

alias

실체화 뷰의 별칭을 명시

ON PREBUILT TABLE

  • 이미 존재하는 테이블을 사용하여 실체화 뷰를 생성

  • 테이블은 생성될 실체화 뷰와 같은 스키마에 속해야 하며 같은 이름을 가지고 있어야 함

  • WITH REDUCED PRECISION: 테이블의 컬럼의 정확도가 실체화 뷰를 정 의한 질의의 결과와 다른 것을 허용

  • WITHOUT REDUCED PRECISION: 테이블의 컬럼의 정확도와 실체화 뷰 를 정의한 질의의 결과가 일치해야 함(기본값)

AT

  • 원격 저장소를 가진 실체화 뷰를 생성할 때 저장소가 위치하는 데이터베이스 링크를 지정

  • 자세한 내용은 “실체화 뷰”를 참고

physical_properties

  • 테이블의 물리적인 속성을 지정

  • 이와 관련된 문법은 “CREATE TABLE”을 참고

materialized_view_props

실체화 뷰의 속성을 지정

USING INDEX

  • 실체화 뷰를 생성할 때 시스템에서 필요한 인덱스를 자동으로 생성

  • 인덱스와 관련된 속성을 지정할 수 있음(기본값)

  • 이와 관련된 문법은 관련 문법은 “CREATE INDEX”를 참고

USING NO INDEX

실체화 뷰를 생성할 때 시스템에서 인덱스를 생성하지 않음

create_mv_refresh

  • 데이터베이스가 실체화 뷰를 리프레시하는 스케줄, 모드, 방법 등을 조절할 수 있음

  • 실체화 뷰가 참조하는 테이블에 변경이 발생하면, 변경된 테이블의 데이터를 반영하기 위해 실체화 뷰를 리프레시함

DISABLE

실체화 뷰를 질의 다시 쓰기에 사용할 수 없는 상태로 설정

ENABLE

실체화 뷰를 질의 다시 쓰기에 사용할 수 있는 상태로 설정(기본값)

QUERY REWRITE

실체화 뷰가 질의 다시 쓰기에 사용될 여부를 설정

AS subquery

  • 실체화 뷰를 생성하면 Tibero는 AS subquery의 질의를 수행하고, 그 결과를 실체화 뷰에 저장

  • 모든 SQL 문장을 사용할 수 있음

  • 하지만, 일부 문장은 장애이어야 하고, 질의에 따라 빠른 리프레시나 질의 다시 쓰기를 사용할 수 없을 수도 있음

– materialized_view_props

구성요소
설명

BUILD

실체화 뷰에 데이터를 언제 삽입할 것인지를 설정

IMMEDIATE

  • 데이터를 실체화 뷰를 생성하는 즉시 삽입

  • 기본값이므로 생략하면 IMMEDIATE로 인식

DEFERRED

  • 처음으로 리프레시할 때 데이터를 삽입

  • 첫 번째 리프레시는 완전 리프레시

  • 첫 번째 리프레시부터 질의 다시 쓰기에 사용될 수 있음

– create_mv_refresh

구성요소
설명

FAST

빠른 리프레시를 수행하려고 할 때 사용

COMPLETE

  • 실체화 뷰를 정의하는 질의를 재수행하여 완전 리프레시를 수행

  • COMPLETE가 명시되면 빠른 리프레시가 가능하더라도 완전 리프레시를 사용 (기본값)

FORCE

빠른 리프레시가 가능하면 빠른 리프레시를 수행하고, 그렇지 않으면 완전 리프레시를 수행

ON DEMAND

  • 사용자가 DBMS_MVIEW 패키지의 REFRESH 프로시저를 호출하는 경우에만 리프레시를 수행

  • 생략하면 ON DEMAND로 인식됨 (기본값)

ON COMMIT

  • ON COMMIT이 명시된 경우 마스터 테이블에 커밋이 일어날 때마다 리프레시를 수행

  • 하지만, START WITH와 NEXT는 명시할 수 없음

  • ON COMMIT과 ON DEMAND는 동시에 명시할 수 없음

START WITH

  • 처음으로 자동 리프레시가 시작될 날짜형 표현식을 명시

  • START WITH는 미래의 시간을 나타내는 값이어야 함

  • NEXT 없이 START WITH만을 명시할 경우 데이터베이스는 한 번만 리프레시를 수행

NEXT

  • 자동 리프레시의 간격을 계산하기 위한 날짜형 표현식을 명시

  • NEXT는 미래의 시간을 나타내는 값이어야 함

  • START WITH 없이 NEXT만 명시한 경우 데이터베이스는 NEXT 표현식을 평가하여 첫 리프레시의 시간을 정함

date

START WITH와 NEXT에 지정할 날짜형 리터럴을 명시

WITH PRIMARY KEY

PRIMARY KEY를 사용하여 리프레시를 수행

WITH ROWID

ROWID를 사용하여 리프레시를 수행

NEVER REFRESH

자동 리프레시를 하지 않음

  • 예제

다음은 CREATE MATERIALIZED VIEW를 사용해 실체화 뷰를 생성하는 예입니다.

다음은 실체화 뷰를 생성하면서 START WITH와 NEXT를 사용해 리프레시하는 시간을 설정하는 예입니다.

위의 예에서는 START WITH 와 NEXT 절을 이용하여 기존의 실체화 뷰를 10분마다 자동으로 리프레시 하는 실체화 뷰를 생성하였다.

다음은 ENABLE QUERY REWRITE와 BUILD DEFERRED를 사용해 실체화 뷰를 생성하는 예입니다.

위의 예를 보면, ENABLE QUERY REWRITE를 사용해 질의 다시 쓰기 기능을 활성화합니다. 그다음 BUILD DEFERRED를 사용해 실체화 뷰에 데이터를 삽입합니다. 그리고 처음으로 리프레시할 때 데이터를 삽입 하도록 설정하였습니다.

hashtag
CREATE MATERIALIZED VIEW LOG

지정된 마스터 테이블에 실체화 뷰 로그를 생성하고 실체화 뷰 로그의 속성을 지정합니다. 실체화 뷰 로그는 실체화 뷰를 리프레시할 때 사용되며, 마스터 테이블의 변경 정보를 기록합니다.

CREATE MATERIALIZED VIEW LOG의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

    • 실체화 뷰 로그를 생성하려면 다음의 조건을 만족해야 합니다.

      • 마스터 테이블을 사용자가 소유하고 있는 경우 CREATE TABLE 시스템 특권이 있어야 합니다.

      • 다른 사용자의 스키마에 실체화 뷰 로그를 생성할 경우에는 CREATE ANY TABLE 시스템 특권과 마스터 테이블에 대한 SELECT 권한 또는 SELECT ANY TABLE 시스템 특권이 있어야 합니다.

  • 구성요소

- create_materialized_view_log

구성요소
설명

schema

  • 실체화 뷰 로그를 생성할 마스터 테이블의 스키마를 명시

  • 생략하면 현재 사용자의 스키마로 인식

table

실체화 뷰 로그를 생성할 마스터 테이블의 이름을 명시

physical_properties

  • 실체화 뷰 로그 테이블의 물리적인 속성을 지정

  • 관련된 문법은 “CREATE TABLE”을 참고합니다.

PRIMARY KEY

실체화 뷰 로그에 마스터 테이블의 변경된 로우의 PRIMARY KEY를 기록

ROWID

실체화 뷰 로그에 마스터 테이블의 변경된 로우의 ROWID를 기록

SEQUENCE

실체화 뷰 로그에 마스터 테이블의 변경된 로우의 순서를 기록

column

실체화 뷰 로그에 기록할 마스터 테이블의 컬럼을 지정

– new_values_clause

구성요소
설명

INCLUDING NEW VALUES

실체화 뷰 로그에 컬럼의 변경 전/후의 값을 모두 기록

EXCLUDING NEW VALUES

실체화 뷰 로그에 컬럼의 변경 전의 값만을 기록 (기본값)

  • 예제

다음은 CREATE MATERIALIZED VIEW LOG를 사용해 실체화 뷰 로그를 생성하는 예입니다.

다음은 실체화 뷰 로그를 생성하면서 컬럼을 지정하는 예입니다. 본 예제에서는 생성된 실체화 뷰 로그에 DNAME과 LOC 컬럼을 기록합니다.

hashtag
CREATE OUTLINE

쿼리 플랜 정보를 저장하기 위해서 아웃라인을 생성합니다. 아웃라인은 해당 쿼리의 플랜 정보를 힌트의 집 합으로 나타내며, 현재는 테이블 액세스 정보와 조인 순서가 힌트로 저장됩니다.

circle-info

참고

아웃라인을 제거하기 위해서는 “DROP OUTLINE”의 내용을 참고합니다.

CREATE OUTLINE의 세부 내용은 다음과 같습니다.

  • 문법

  • 구성요소

구성요소
설명

OR REPLACE

생성할 아웃라인이 기존에 존재하는 아웃라인이라면, 그 아웃라인을 제거하고 새로 생성

outline_name

생성할 아웃라인의 이름

statement

아웃라인을 생성할 쿼리를 지정

  • 예제

다음은 CREATE OUTLINE을 사용해 아웃라인을 생성하는 예입니다.

또는 CREATE_STORED_OUTLINES라는 파라미터를 켜면 수행되는 쿼리들에 대해서 SYS_OUTLINE으로 시작하는 아웃라인이 자동으로 생성됩니다.

USE_STORED_OUTLINES라는 파라미터를 켜면 쿼리 수행시마다 적용할 수 있는 아웃라인을 찾아서 적용합니다. 아웃라인은 쿼리가 정확하게 매치될 때에만 같은 쿼리로 인식하고 적용하므로 빈칸 등에 유 의해야 합니다.

hashtag
CREATE PACKAGE

새로운 패키지를 생성합니다. 패키지란 서로 관련 있는 프러시저나 함수, 그리고 다른 프로그램의 객체를 데 이터베이스 내에 한 영역으로 모아서 저장한 것을 의미합니다. 패키지는 이러한 객체를 선언하는 역할을 하 며, 패키지 본문은 객체의 실제 내용을 정의하는 역할을 합니다.

CREATE PACKAGE의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

    • 사용자 자신의 스키마에 패키지를 생성하려면 CREATE PROCEDURE 시스템 특권이 있어야 합니다.

    • 다른 사용자의 스키마에 패키지를 생성하려면 CREATE ANY PROCEDURE 시스템 특권이 있어야 합니다.

  • 구성요소

- create_package

구성요소
설명

OR REPLACE

  • 해당 항목을 설정하면 이미 존재하는 패키지라도 다시 생성할 수 있음

  • 패키지를 변경하고자 할 때 명세를 제거하고, 다시 생성하고, 스키마 객체 특권을 설정하는 단계를 반복하는 것을 피할 수 있음

  • 패키지의 명세가 바뀌면 패키지 본문은 무효가 되며, 다음번에 사용하려고 하면 패키지를 재컴파일함

schema

변경할 패키지가 속해 있는 스키마를 명시

package_name

변경할 패키지의 이름을 명시

invoker_right_clause

호출자 권한 패키지를 생성할지 아니면 정의자 권한 패키지를 생성할지를 결정

IS

  • IS나 AS는 기호에 맞게 선택할 수 있으며, 둘의 차이는 없음

  • IS 다음에는 패키지의 본문이 옴

AS

IS와 동일합니다. AS 다음에는 패키지의 본문이 옴

pkg_spec_source

  • 패키지의 명세를 지정

  • 자세한 내용은 "Tibero tbPSM 안내서"를 참고

– invoker_right_clause

구성요소
설명

AUTHID CURRENT_USER

  • 호출자 권한 패키지를 생성

  • 이 패키지의 프러시저 또는 함수가 수행 될 때는 현재 사용자의 스키마에서 수행되는 것으로 간주하며, 특권도 현 재 사용자의 특권을 가지고 수행됨

AUTHID DEFINER

  • 정의자 권한 패키지를 생성

  • 이 패키지의 프러시저 또는 함수가 수행 될 때는 정의자의 스키마와 특권을 가지고 패키지의 프러시저와 함수를 수행

  • 기본은 정의자 권한 패키지

  • 예제

다음은 CREATE PACKAGE를 사용해 패키지를 생성하는 예입니다.

hashtag

hashtag
CREATE PACKAGE BODY

저장된 패키지의 본문을 생성합니다.

CREATE PACKAGE BODY의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

    • 사용자의 스키마에 패키지를 생성하려면 CREATE PROCEDURE 시스템 특권이 있어야 합니다.

    • 다른 사용자의 스키마에 패키지를 생성하려면 CREATE ANY PROCEDURE 시스템 특권이 있어야 합니다.

  • 구성요소

구성요소
설명

OR REPLACE

  • OR REPLACE를 명시하면 이미 존재하는 패키지 본문이라도 다시 생성할 수 있음

  • 패키지 본문을 변경하고자 할 때 패키지 본문을 제거하고, 다시 생성하고, 스키마 객체 특권을 설정하는 단계를 반복하는 것을 피할 수 있음

  • 패키지 본문이 변경되면 패키지 본문을 컴파일해서 새로운 패키지 본문으로 적용함

schema

변경할 패키지가 속해 있는 스키마를 명시

package_name

변경할 패키지의 이름을 명시

IS

  • IS나 AS는 기호에 맞게 선택할 수 있으며, 둘의 차이는 없음

  • IS 다음에는 패키지의 본문이 옴

AS

IS와 동일합니다. AS 다음에는 패키지의 본문이 옴

psm_package_body_source

  • 패키지 본문을 지정

  • 자세한 내용은 "Tibero tbPSM 안내서"를 참고

  • 예제

다음은 CREATE PACKAGE BODY를 사용하는 예입니다.

hashtag

hashtag
CREATE PROCEDURE

사용자 프러시저를 새로 정의하거나 기존의 프러시저로 대체합니다. 사용자 프러시저는 tbPSM 프로그램이 며, Tibero 서버에서 저장되고 실행됩니다.

사용자 프러시저가 사용자 함수와 다른 점은 반환값이 없으며 질의 또는 DML 문장에서 사용될 수 없습니다는 것입니다. 사용자 프러시저는 다른 프러시저에서 직접 호출되거나 tbSQL 유틸리티에서 EXECUTE를 이용 하여 호출합니다.

CREATE PROCEDURE의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

    • 사용자가 자신의 스키마에 프러시저를 생성하고자 하면 CREATE PROCEDURE 시스템 특권을 부여 받아야 합니다.

    • 다른 사용자의 스키마에 프러시저를 생성하거나 변경하고자 하면 CREATE ANY PROCEDURE 또 는 ALTER ANY PROCEDURE 시스템 특권을 부여받아야 합니다.

  • 구성요소

– create_procedure

구성요소
설명

OR REPLACE

  • 이미 존재하는 프로시저를 다시 정의하고자 할 때 사용

  • OR REPLACE가 포함되면 해당 프로시저를 재컴파일

  • 프로시저를 제거하고 다시 생성하는 것과의 차이는 OR REPLACE를 이용하면 해당 프로시저에 기존의 특권이 그대로 유지된다는 점

schema

  • 프러시저가 속해 있는 스키마를 명시

  • 생략하면 현재 사용자의 스키마로 인식됨

procedure_name

생성하고자 하는 프러시저의 이름을 명시

argument

  • 프러시저의 파라미터

  • 프러시저의 파라미터는 0개 이상이 될 수 있음

  • 파라미터가 0개이면 파라미터를 감싸는 괄호를 생략할 수 있음

IN

  • 프러시저의 파라미터의 전달 방향에 따른 구분

  • IN 파라미터는 외부로부터 값을 입력 받는다. 디폴트는 IN 파라미터

  • 프러시저에서는 현재 트랜잭션에 대해 COMMIT, ROLLBACK, SAVEPOINT를 수행할 수 없고 DDL 문장을 수행할 수 없음

  • 또한, 현재 액세스 중인 테이블에 대한 갱신도 수행할 수 없음

OUT

  • 프러시저의 파라미터의 전달 방향에 따른 구분

  • OUT 파라미터는 프러시저 내부로부터 값을 출력

  • DML 문장에 포함된 프러시저는 OUT 파라미터를 가질 수 없음

  • DML 문장에 포함된 프러시저로부터 직접 또는 간접적으로 호출되는 프러시저는 OUT 또는 IN OUT 파라미터를 가질 수 있으나, 나머지는 불가능

IN OUT

  • 프러시저의 파라미터의 전달 방향에 따른 구분

  • IN OUT 파라미터는 입력과 출력 모두에 사용됨

  • DML 문장에 포함된 프러시저는 IN OUT 파라미터를 가질 수 없음

NOCOPY

  • 파라미터의 값을 가리키는 포인터(Pointer)를 전달

  • 파라미터의 값을 복사하지 않기 때문에 전달 속도가 빠름

datatype

  • 프러시저의 파라미터의 데이터 타입

  • 프러시저의 파라미터의 데이터 타입은 환경의 데이터 타입 또는 tbPSM에서 지원하는 모든 데이터 타입이 가능

  • 반환값의 데이터 타입을 선언할 때 문자열의 길이, 숫자의 정밀도와 스케일은 지정할 수 없음

invoker_right_clause

  • 프러시저를 호출자 권한 프러시저 또는 정의자(DEFNER) 권한 프러시저로 선언

  • 사용자 프러시저는 호출자 권한 프러시저 또는 정의자 권한 프러시저로 구분할 수 있음

  • 이는 프러시저를 실행 할 때 어떤 사용자의 특권을 이용하여 실행할 것인지, 액세스하고자 하는 테이블 등의 객체는 어떤 스키마에서 찾을 것인지 등을 결정

  • 디폴트는 정의자 권한 프러시저

IS

  • IS나 AS는 기호에 맞게 선택할 수 있으며, 둘의 차이는 없음

  • IS 다음에는 프러시저의 본문이 옴

AS

IS와 동일합니다. AS 다음에는 프러시저의 본문이 옴

psm_source

  • PSM 소스 코드가 오는 부분

  • 자세한 내용은 "Tibero tbPSM 안내서"를 참고

call_spec

  • 외부 함수를 호출하기 위한 명세를 지정

  • 자세한 내용은 "Tibero tbPSM 안내서"를 참고

– invoker_right_clause

구성요소
설명

AUTHID CURRENT_USER

  • 프러시저를 호출자 권한 프러시저로 선언

  • 호출자 권한 프러시저로 선언하면, 현재 사용자의 특권을 이용하며 현재 사용자의 스키마에서 액세스할 객체를 찾음

  • 따라서, 프러시저를 호출 하는 사용자가 달라지면 가능한 작업의 범위와 액세스하는 스키마 객체도 달라짐

  • 이러한 프러시저는 여러 사용자가 공통으로 동일한 작업을 수행하고자 할 때에 유용

AUTHID DEFINER

  • 프러시저를 정의자 권한 프러시저로 선언

  • 정의자 권한 프러시저로 선언하면, 프러시저를 정의한 사용자의 특권을 이용하고 그 사용자의 스키마에서 액세스할 객체를 찾음

  • 따라서, 호출 자에 관계없이 작업의 범위와 액세스하는 스키마 객체가 항상 일정

  • 이러한 프러시저는 데이터 사전 등의 시스템 데이터의 일부를 일반 사용 자가 액세스할 때에 유용

  • 예제

다음은 CREATE PROCEDURE를 사용해 사용자 프러시저를 생성하는 예입니다.

hashtag

hashtag
CREATE PROFILE

새로운 프로파일을 생성합니다.

circle-info

참고

프로파일의 정보를 변경하거나 제거하기 위해서는 “ALTER PROFILE”, “DROP PROFILE”의 내용을 참고합니다.

CREATE PROFILE의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

    • 프로파일을 생성하기 위해서는 CREATE PROFILE 시스템 특권이 필요합니다.

  • 구성요소

– create_profile

구성요소
설명

not_exist

IF NOT EXISTS 해당 옵션을 명시하면

  • 동일한 이름의 OBJECT가 이미 존재하는 경우에도 에러 로그를 발생 시키지 않고 성공 메시지를 반환

  • OBJECT가 존재하지 않는 경우에는 기존 CREATE 문과 동일하게 동 작

profile_name

  • 생성할 프로파일의 이름

  • 프로파일 이름은 VARCHAR 데이터 타입으로 저장되고 길이는 최대 255자까지 가능

password_parameters

사용자 계정 접속 및 패스워드 관련 세부 설정 내용

– password_parameters

구성요소
설명

FAILED_LOGIN_ATTEMPTS

잘못된 패스워드로 로그인 시도한 경우 사용자 계정을 잠글 때까지 로그인 시도 허용 횟수를 지정

LOGIN_PERIOD

이 값이 지정되어 있을 경우 마지막 로그인 후 지정된 시간이 지나면 계정이 잠김

PASSWORD_LIFE_TIME

  • 패스워드 만료 기간을 설정

  • 숫자와 수식 두 가지 형태로 지정할 수 있음

  • 숫자로 지정할 경우 단위는 일(day)

  • 예를 들어 30으로 지정하면 패스워드 만료 일자가 30일 후가 됨

  • 해당 값을 1일 미만으로 지정하는 등 특별한 용도로 사용하기 위해 수식을 사용할 수 있음

  • 예를 들어 1/1440으로 지정하면 패스워드 만료 일자가 1분 후가 됨

PASSWORD_REUSE_TIME

  • 패스워드 재사용 금지 기간을 설정

  • 숫자와 수식 두 가지 형태로 지정할 수 있음

  • 예를 들어 해당 값을 30으로 설정하면 30일 동안 동일한 패스워드로 다시 변경할 수 없음

PASSWORD_REUSE_MAX

  • 설정된 값 수만큼 최근 변경한 패스워드는 재사용할 수 없음

  • 예를 들어 해당 값을 10으로 지정하면 현재 패스워드를 재사용하기 위해서는 10회 이상 다른 값으로 먼저 패스워드를 변경해야 함

PASSWORD_LOCK_TIME

  • 패스워드 오류 횟수 초과로 계정이 잠금 상태가 되었을 때 자동으로 잠금 상태를 해제하는 기간을 설정

  • 숫자와 수식 두 가지 형태로 지정할 수 있음

  • 예를 들어 1/1440으로 지정하면 1분 후 자동으로 잠금 상태가 해제됨

PASSWORD_GRACE_TIME

  • 패스워드 사용기간(PASSWORD_LIFE_TIME) 만료 후 패스워드 만료 경고를 보내는 기간을 설정

  • 숫자와 수식 두 가지 형태로 지정할 수 있음

  • 경고를 보내는 기간은 패스워드 사용기간 만료후 첫 접속한 시점부터 계산

  • 예를 들어 PASSWORD_LIFE_TIME을 30, PASSWORD_GRACE_TIME을 3으로 설정하면 30일이 지난 후 첫 접속부터 3일간 패스워드 만료 경고가 나타나고 다시 3일이 지나면 계정이 잠금 상태가 됨

  • 패스워드 만료 경고는 tsql에서는 동작하며 다른 방식으로 접속하는 경우(OCI, JDBC 등) 패스워드 만료 에러를 반환

SESSIONS_PER_USER

유저당 접속 가능한 세션 수를 제한

PASSWORD_VERIFY_FUNCTION

  • 패스워드를 변경할 때 패스워드 문자열을 검사하여 유효성을 확인하는 PSM 함수를 지정

  • PSM 함수는 기본으로 들어있는 함수를 지정하거나 다른 함수를 정의해서 지정할 수 있음

  • 아무것도 지정하지 않으면 데이터베이스를 생성할 때 미리 만들어진 NULL_VERIFY_FUNCTION이라는 함수를 기본으로 사용

  • 이 함수는 패스워드에 아무런 제약을 두지 않음

  • Tibero에서 기본 제공하는 PASSWORD_VERIFY_FUNCTION에 대한 자세한 설명은 "Tibero 관리자 안내서"를 참고

  • 예제

– create_profile

다음은 프로파일을 생성하는 예입니다.

이 예제대로 프로파일을 생성하면 해당 프로파일을 사용하는 사용자는 패스워드 입력 오류를 3회 발 생한 경우 1분간 계정 잠금 상태가 되며, 패스워드 유효기간은 90일이고 패스워드 변경시 최근 10개 의 패스워드는 재사용할 수 없습니다. 또한, 패스워드 만료후 10일간 패스워드 만료 경고를 받게됩니다. 패 스워드를 변경할 때 verify_function이라는 검증 함수로 패스워드의 유효성을 검사하게됩니다.

아무런 limit도 지정하지 않는 경우(다음과 같이 LIMIT 절을 지정하지 않은 경우에는) 데이터베이스를 생성할 때 만들어진 프로파일인 'DEFAULT'와 동일한 limit으로 프로파일이 생성됩니다.

circle-info

참고

SYS 사용자에 한하여 profile이 적용되어도 패스워드 기한만료, 입력 오류 등으로 인해 계정이 잠금 상태가 되지 않습니다.

그리고 파라미터들 중 일부만 지정한 경우에는 지정한 값을 제외한 나머지 값들이 'DEFAULT' 프로 파일과 동일한 값으로 생성됩니다. 즉, 'DEFAULT'라는 이름의 프로파일은 다른 프로파일을 생성할 때 기본값으로 참조되는 값이며 이 기본값을 조정하고 싶으면 ALTER PROFILE 명령을 이용하면 됩니다.

circle-info

참고

DBA_PROFILES 뷰를 통해 각 프로파일별 파라미터 값을 조회할 수 있습니다.

circle-info

참고

PASSWORD_REUSE_TIME, PASSWORD_REUSE_MAX 두 파라미터는 서로 함께 설정되어야 합니다. 사용자가 패스워드를 재사용하려면 패스워드를 PASSWORD_REUSE_MAX 값만큼 변경했으면서 동시에 PASSWORD_REUSE_TIME 값만큼 날짜가 지나야 합니다.

두 파라미터 중 하나를 UNLIM ITED로 설정하면 사용자는 패스워드를 재사용할 수 없습니다.

hashtag
CREATE ROLE

특권의 집합인 역할을 생성합니다. 역할은 특권이나 다른 역할을 포함할 수 있습니다. 하지만, CREATE ROLE 문장으로 만들어진 역할은 아무런 특권이나 집합을 포함하지 않은 상태로 생성됩니다. 만들어진 역할에 어 떠한 특권이나 역할을 포함하고자 할 때는 GRANT를 사용합니다.

circle-info

참고

  1. 생성한 역할의 정보를 변경하거나 제거하고자 할 때는 “ALTER ROLE”, “DROP ROLE”을 참고합니다.

  2. 생성한 역할을 사용하는 방법은 “GRANT”, “REVOKE”, “SET ROLE”을 참고합니다.

CREATE ROLE의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

    • CREATE ROLE 시스템 특권이 필요합니다.

  • 구성요소

구성요소
설명

not_exist

  • IF NOT EXISTS. 해당 옵션을 명시하면 동일한 이름의 OBJECT가 이미 존재하는 경우에도 에러 로그를 발생시키지 않고 성공 메시지를 반환

  • OBJECT가 존재하지 않는 경우에는 기존 CREATE 문과 동일하게 동작

role_name

  • 생성할 역할의 이름

  • 역할의 이름은 VARCHAR 데이터 타입으로 저장되며 길이는 최대 30자까지 가능

  • 전체 데이터베이스의 다른 역할 또는 사용자 이름과 중복되면 안 됨

NOT IDENTIFIED

  • 생성하는 역할에 패스워드를 사용하지 않음

  • 기본값이므로 이 부분을 생략하면 NOT IDENTIFIED로 인식됨

IDENTIFIED BY

  • 생성하는 역할에 패스워드를 설정

  • 패스워드가 설정된 역할은 SET ROLE 문장을 사용해 역할을 활성화하려 할 때 설정된 패스워드를 입력해야 함

  • 패스워드 사용에 대한 자세한 내용은 “SET ROLE”을 참고

password

  • 역할에 설정할 패스워드를 명시

  • 특수 문자를 쓰기 위해서는 따옴표(" 또는 ')를 사용해서 패스워드를 감싸야 함

  • 대소문자가 구분되는 패스워드를 사용하려면 작은따옴표(")로 패스워드를 감싸야 함

  • 초기화 파라미터 'USE_CASE_SENSITIVE_PASSWORD'를 'Y'로 설정할 경 우 따옴표를 사용하지 않아도 기본적으로 대소문자를 구분하도록 패스워드가 생성됨

  • 예제

다음은 NOT IDENTIFIED를 사용해 역할을 생성하는 예입니다.

위의 예와 같이, NOT IDENTIFIED 절을 사용해 역할을 생성하거나 모두 생략해서 만든 역할은 아무런 제약 없이 SET ROLE 문장에서 사용할 수 있습니다.

다음은 역할을 생성할 때 IDENTIFIED를 사용해 패스워드를 설정하는 예입니다.

IDENTIFIED를 사용하여 패스워드를 설정한 역할은 NOT IDENTIFIED를 사용한 것과 다르게 동작합니다. 위의 예와 같이 SET ROLE 문장에서 역할을 활성화할 때에 생성할 때 지정한 패스워드를 입력해 주어 야만 동작하는 것을 볼 수 있습니다.

hashtag
CREATE SEQUENCE

사용자가 소유한 스키마 또는 지정된 스키마에 포함되는 시퀀스를 생성합니다.

circle-info

참고

시퀀스를 변경, 제거하기 위해서는 “ALTER SEQUENCE”와 “DROP SEQUENCE”의 내용을 참고합니다.

CREATE SEQUENCE의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

    • 시퀀스를 생성하기 위해서는 CREATE SEQUENCE 시스템 특권이 필요합니다.

    • 다른 사용자가 소유한 스키마의 시퀀스를 생성하기 위해서는 CREATE ANY SEQUENCE 시스템 특 권이 필요합니다.

  • 구성요소

    • create_sequence

구성요소
설명

not_exist

  • IF NOT EXISTS

  • 해당 옵션을 명시하면 동일한 이름의 OBJECT가 이미 존재하는 경우에도 에러 로그를 발생시키지 않고 성공 메시지를 반환

  • OBJECT가 존재하지 않는 경우에는 기존 CREATE 문과 동일하게 동작

schema

  • 생성할 시퀀스를 포함하는 스키마의 이름

  • 생략하면 현재 사용자의 스키마로 인식됨

sequence_name

생성할 시퀀스의 이름

시퀀스의 이름은 다음과 같은 특징이 있습니다.

  • VARCHAR 데이터 타입으로 저장되고, 길이는 최대 30자까지 가능

  • 시퀀스의 이름은 테이블과 같은 네임스페이스를 사용하므로 스키마의 다른 시퀀스, 테이블, 동의어, PSM의 이름과 중복되면 안 됨

sequence_attributes

시퀀스의 속성을 정의하는 부분으로 생략할 수 있음

– sequence_attributes

구성요소
설명

INCREMENT BY

  • 시퀀스의 간격을 지정

  • 이 값을 양수로 입력하면 시퀀스의 값이 증가하게 되고, 음수로 입력하면 시퀀스의 값이 감소하게 됨

  • 지정하지 않으면 디폴트 1로 간격이 지정됨

  • 이 값은 MAXVALUE에서 MINVALUE를 뺀 값보다 클 수 없음

START WITH

  • 시퀀스의 시작 값을 지정

  • 시작 값은 MINVALUE와 MAXVALUE 사이의 값을 지정할 수 있음

  • 시작 값을 지정하지 않으면 INCREMENT BY 값이 양수인 경우 MINVALUE가, INCREMENT BY 값이 음수인 경우 MAXVALUE가 시작 값이 됨

NOMAXVALUE

  • MAXVALUE를 지정하지 않는 것과 같음

  • MAXVALUE는 시퀀스의 증가 값이 양수인 경우 시퀀스가 가질 수 있는 가장 큰 값인 INT64_MAX가 되고 증가 값이 음수인 경우 -1이 됨

MAXVALUE

  • MAXVALUE의 값을 지정

  • MAXVALUE는 MINVALUE보다 작아서는 안 됨

  • 지정하지 않으면 NOMAXVALUE와 같은 값으로 동작

NOMINVALUE

  • MINVALUE를 지정하지 않는 것과 같음

  • MINVALUE는 시퀀스의 증가 값이 양수인 경우 1의 값을 가지고, 증가 값이 음수인 경우 시퀀스가 가질 수 있는 가장 작은 값인 INT64_MIN이 됨

MINVALUE

  • MINVALUE의 값을 지정

  • MINVALUE는 MAXVALUE보다 클 수 없음

  • 지정하지 않으면 NOMINVALUE와 같은 값으로 동작

CYCLE

  • CYCLE이 지정되면 MAXVALUE나 MINVALUE에 도달해도 계속 시퀀스 값을 생성

  • 증가 값이 양수일 때 시퀀스의 값이 MAXVALUE를 넘게 되면 MINVALUE 값을 주게 되고, 증가 값이 음수일 때 시퀀스 값이 MINVALUE보다 작아지면 MAXVALUE 값을 주게 됨

NOCYCLE

  • CYCLE과 반대로 MAXVALUE 또는 MINVALUE에 도달하게 되면 더 이상 값을 만들지 않음

  • CYCLE이나 NOCYCLE 둘 다 지정하지 않으면 NOCYCLE이 기본값이 큼

CACHE

  • 시퀀스의 속도를 높이기 위해 시퀀스 캐시에 지정된 개수만큼의 시퀀스 값을 저장해 두고 시퀀스 값을 요청하면 시퀀스 캐시에서 받아오게 됨

  • 저장해 둔 시퀀스 값을 다 사용하게 되면 새로 그만큼 더 받아오게 되며, 매번 데이터 사전의 값을 수정하게 됨

  • 즉, CACHE로 임의의 수 N을 지정하였다면, NOCACHE로 사용할 때보다 1/N의 데이터 사전 수정이 이루어지므로 속도를 높일 수 있음

  • 단, 비정상 종료가 발생한 경우 캐시에 저장된 값은 없어짐 (기본값: 20)

NOCACHE

  • 시퀀스 캐시를 사용하지 않고 매번 직접 값을 받아옴

  • 따라서 매번 데이터 사전을 수정하게 됨

ORDER

  • 클러스터 환경에서 노드 간에 발급되는 시퀀스 값의 순서를 유지

  • 노드에 관계 없이 요청된 순서대로 시퀀스 값이 발급됨

  • 클러스터 환경으로 설정한 경우에만 지정할 수 있음

NOORDER

  • ORDER와 반대로 클러스터 환경에서 노드 간에 발급되는 시퀀스 값의 순서를 유지하지 않음

  • 노드별로 각각의 시퀀스 캐시를 유지하므로 한 노드 안에서는 요청된 순서대로 시퀀스 값이 발급되지만, 전체 노드에서는 요청된 순서와 발급되는 시퀀스 값의 순서가 다를 수 있음

  • ORDER나 NOORDER 둘 다 지정하지 않으면 NOORDER가 기본값이 됨

  • 예제

다음은 CREATE SEQUENCE를 사용해 TEST_SEQ라는 시퀀스를 생성하는 예입니다.

위의 예에서 TEST_SEQ는 40 ~ 200까지의 값을 가지는 시퀀스입니다. TEST_SEQ.nextval을 사용하여 처음 값을 얻으면 시작 값인 100이 출력됩니다. 그다음부터는 2씩 증가하게 됩니다. 200에 도달하면 CYCLE 옵션 때문에 다시 40으로 돌아가게 됩니다.

hashtag
CREATE SYNONYM

사용자가 소유한 스키마나 다른 사용자가 소유한 스키마에 속하는 동의어를 생성합니다. 동의어를 생성할 수 있는 스키마 객체는 다음과 같습니다.

  • 테이블

  • 뷰

  • 시퀀스

  • PSM 함수

  • PSM 프러시저

  • 동의어

circle-info

참고

동의어를 제거하기 위해서는 “DROP SYNONYM”의 내용을 참고합니다.

CREATE SYNONYM의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

    • 사용자가 소유한 스키마의 동의어를 생성하기 위해서는 CREATE SYNONYM 시스템 특권이 필요합니다.

    • 다른 사용자가 소유한 스키마의 동의어를 생성하기 위해서는 CREATE ANY SYNONYM 시스템 특권 이 필요합니다.

    • 공용 동의어를 생성하기 위해서는 CREATE PUBLIC SYNONYM 특권이 필요합니다.

  • 구성요소

구성요소
설명

OR REPLACE

  • 생성할 동의어가 기존에 존재하는 동의어라면, 그 동의어를 제거하고 새로 생성

  • 동의어를 삭제하고 다시 생성하는 것과의 차이는 대상 동의어에 관련된 기존의 특권과 참조가 그대로 유지된다는 점

PUBLIC

  • 공용 동의어를 만듦

  • 공용 동의어는 모든 사용자가 접근할 수 있지만, 공용 동의어가 가리키는 객체를 사용하기 위해서는 해당 객체에 대한 권한이 있어야 함

schema

  • 생성할 동의어를 포함하는 스키마의 이름

  • 생략하면 현재 사용자의 스키마로 인식됨

synonym_name

  • 생성할 동의어의 이름

  • 동의어의 이름은 VARCHAR 데이터 타입으로 저장되고, 길이는 최대 30자까지 가능함

  • 동의어의 이름은 테이블과 같은 네임스페이스를 사용하므로 스키마의 다른 동의어, 공용 동의어, 테이블, 뷰, 시퀀스, 함수와 프로시저의 이름과 중복되면 안 됨

FOR schema

  • FOR는 동의어가 가리키는 대상을 설정

  • schema는 생성할 동의어의 대상이 되는 객체를 포함하는 스키마의 이름

  • 생략하면 dblink의 명시 했을 경우 dblink의 접속 사용자 이름으로 인식되고, 명시하지 않았을 경우 현재 사용자의 스키마로 인식됨

  • 만약 명시한 dblink가 존재하지 않거나 사용할 수 없는 경우에는 null로 인식됨

object_name

  • 생성할 동의어의 대상이 되는 객체의 이름

  • 동의어가 가리키는 대상이 꼭 존재하지 않아도 되고, 접근할 수 있는 권한이 필요하지도 않음

  • 하지만, 그러한 경우에는 동의어를 사용하여 접근할 때 에러가 발생하게 됨

dblink

  • 데이터베이스 링크로 연결된 객체에 동의어를 생성할 때 데이터베이스 링크의 이름을 명시

  • 데이터베이스 링크 앞에는 항상 '@'를 붙여야 함

  • 데이터베이스 링크에 대한 자세한 내용은 "Tibero 관리자 안내서"를 참고

  • 예제

다음은 CREATE SYNONYM을 사용해 동의어를 생성하는 예입니다.

본 예제에서는 사용자(또는 스키마) tibero에 속한 emp라는 동의를 생성합니다.

다음은 CREATE PUBLIC SYNONYM을 사용해 공용 동의어를 생성하는 예입니다. 본 예제에서는 사용자SYS에 속한 t에 접근할 수 있는 pt라는 공용 동의어를 생성합니다.

공용 동의어 pt가 생성되면 모든 사용자가 SYS의 t에 접근할 수 있지만 t를 사용하기 위해서는 사용자 가 그에 해당하는 특권을 가지고 있어야 합니다.

hashtag
CREATE TABLE

테이블을 생성합니다.

CREATE TABLE의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

    • 사용자가 소유한 스키마에 테이블을 생성하기 위해서는 CREATE TABLE 시스템 특권이 있어야 한 다.

    • 다른 사용자의 스키마에 테이블을 생성하기 위해서는 CREATE ANY TABLE 시스템 특권이 있어야 합니다.

  • 구성요소

- create_table

구성요소
설명

GLOBAL TEMPORARY

  • 임시 테이블(Temporary Table)을 생성하기 위해 지정

  • 임시 테이블의 스키마 자체는 일반 테이블과 다를 바 없이 모든 세션에 동일하게 보이지만, 테이블의 데이터는 각각의 세션이 따로 유지하게 됨

  • 따라서 한 세션의 임시 테이블의 데이터는 다른 세션에서 접근할 수도, 볼 수도 없음

  • 오직 자신의 세션에서만 해당 테이블의 데이터를 볼 수 있음

  • 임시 테이블의 데이터는 영속 테이블 스페이스가 아닌 임시 테이블 스페이스에 저장되고, 세션의 종료와 동시에 임시 테이블의 데이터는 모두 제거됨

  • 트랜잭션을 커밋할 때 임시 테이블의 데이터 처리 방식을 지정할 수 있는 ON COMMIT 옵션을 지원

  • 임시 테이블은 sgmt_attr, colprop를 지정할 수 없고, FOREIGN KEY 제약조건을 지정할 수 없음

not_exist

IF NOT EXISTS. 해당 옵션을 명시하면

  • 동일한 이름의 OBJECT가 이미 존재하는 경우에도 에러 로그를 발생 시키지 않고 성공 메시지를 반환

  • OBJECT가 존재하지 않는 경우에는 기존 CREATE 문과 동일하게 동작

schema

  • 생성할 테이블이 속하게 될 스키마를 명시

  • 생략하면 현재 사용자의 스키마로 인식됨

table_name

생성할 테이블의 이름을 명시

relational_properties

테이블의 구성요소인 컬럼, 제약조건 등을 설정

ON COMMIT DELETE ROWS

  • 임시 테이블에서만 의미가 있는 옵션

  • ON COMMIT DELETE ROWS를 지정하면 트랜잭션을 커밋할 때 임시 테이블의 데이터를 깨끗하게 제거

  • 그러나 이렇게 저장된 임시 테이블의 정보는 옵션에 관계없이 세션의 종료와 동시에 모두 제거됨

  • 임시 테이블을 생성할 때 ON COMMIT 옵션을 지정하지 않았다면 디폴트로 ON COMMIT DELETE ROWS로 생성됨

ON COMMIT PRESERVE ROWS

ON COMMIT PRESERVE ROWS를 지정하면 트랜잭션을 커밋할 때 데이터를 테이블에 저장하게 됨

physical_properties

테이블의 물리적인 속성을 지정

table_properties

파티셔닝, 대용량 객체형의 저장 방식 등 테이블의 속성을 지정

- relational_properties

구성요소
설명

column_definition

테이블의 컬럼을 정의

outofline_constraint

  • 테이블의 제약조건을 지정

  • 자세한 내용은 “제약조건”을 참고

- coldef

구성요소
설명

datatype

컬럼의 데이터 타입을 명시

identity_clause

  • identity column 옵션을 명시

  • identity_clause 기능은 Tibero 7 FS02 릴리즈부터 지원

DEFAULT expr

  • 컬럼의 기본값을 지정

  • 시퀀스의 의사 컬럼인 CURRVAL과 NEXTVAL을 지정할 수 있음

  • 자세한 내용은 “스키마 객체의 이름” 시퀀스를 참고

ENCRYPT encryption_spec

컬럼을 암호화하고 암호화 옵션을 지정

inline_constraint

  • 테이블의 제약조건을 지정

  • 자세한 내용은 “제약조건”을 참고

- identity_clause

구성요소
설명

ALWAYS

시퀀스 생성기로만 값을 할당하며, 사용자가 직접 값을 지정하려고 하 면 오류가 발생

BY DEFAULT

기본적으로 시퀀스 값이 할당되지만, 사용자가 명시적으로 값을 지정할 수 있음

ON NULL

INSERT 시 NULL 값이 입력될 경우 시퀀스 값을 할당

sequence_attributes

시퀀스의 시작 값, 증가 값 등을 명시

- encryption_spec

구성요소
설명

USING encryption_algorithm

컬럼을 암호화할 알고리즘을 명시

encryption_algorithm은 문자열로 지정

Tibero에서 지원하는 암호화 알고리즘은 다음과 같음

  • DES

  • 3DES168

  • AES128

  • AES192 (기본값)

  • AES256

  • ARIA128

  • ARIA192

  • ARIA256

  • SEED

  • GOST

  • SM4

SALT, NO SALT

  • 보안을 강화하는 SALT 기능을 사용할지의 여부를 지정

  • SALT 기능은 컬럼 값이 같더라도 암호화 후의 값을 다르게 생성하여 보안을 강화

  • 단, SALT 기능은 같은 값을 매번 다르게 암호화하므로 해당 컬럼에 인덱스를 생성할 수 없음

  • 지정하지 않으면 기본값은 SALT

- physical_properties

구성요소
설명

sgmt_attr

sgmt_attr 관련 문법은 “Sgmt_attr”를 참고

table_compression

테이블의 압축 여부를 지정

ORGANIZATION EXTERNAL

외부 데이터 파일을 지정할 때 external_table_clause 앞에 명시해야 함

external_table_clause

  • 데이터베이스 외부 파일의 데이터에 대한 메타데이터(metadata)를 지정하여 외부 데이터를 읽기 전용 테이블로 사용할 수 있도록 함

  • 외부 테이블을 생성할 때에는 컬럼의 정의 이외의 다른 속성은 지정할 수 없음

ORGANIZATION INDEX

  • index organized table을 생성할 때 사용

  • 이 테이블은 기본 키 인덱스 안에 데이터 행이 함께 저장되는 구조를 가짐

[기본 규칙]

  • Global Temporary IOT는 지원하지 않음

  • Primary Key 인덱스는 IOT 구조를 따라야 하며, 별도 지정(USING INDEX)이나 글로벌 파티션 인덱스는 허용되지 않음

  • Interval 파티셔닝은 지원하지 않음

  • Primary Key는 반드시 ENABLE 상태로 생성되며 DEFERRABLE/DISABLE은 허용되지 않음

index_org_table_clause

index organized table 관련하여 정보 설정을 해줄 때 사용

- table_compression

구성요소
설명

COMPRESS

DPI/DPL을 사용 중일 때만 테이블을 압축

NOCOMPRESS

테이블을 압축하지 않음

COMPRESS FOR OLTP

DPI/DPL이 아닌 일반 DML일 때만 테이블을 압축

COMPRESS FOR DIRECT_LOAD OPERATIONS

DPI/DPL을 사용 중일 때만 테이블을 압축

COMPRESS FOR ALL OPERATIONS

모든 DML에 대해 테이블을 압축

ROW STORE COMPRESS ADVANCED

DPI/DPL이 아닌 일반 DML일 때만 테이블을 압축

COMPRESSED TABLE에서는 DROP COLUMN, SET UNUSED, DROP UNUSED COLUMNS 구문을 사용할 수 없습니다.

COMPRESSED TABLE에서 MERGE, SPLIT 파티션 시 UPDATE GLOBAL INDEXES, UPDATE INDEXES 구문도 지원하지 않습니다.

- external_table_clause

구성요소
설명

DEFAULT DIRECTORY directory

  • 외부 데이터의 파일을 지정할 때 디폴트 디렉터리를 설정

  • 디렉터리 생성에 관한 내용은 “CREATE DIRECTORY”를 참고

ACCESS PARAMETERS

  • 외부 데이터의 파일을 접근하기 위한 메타데이터를 지정

  • 자세한 내용은 “Tibero 유틸리티 안내서”를 참고

tbloader_format_spec

"Tibero 유틸리티 안내서"의 tbLoader 부분을 참고.

LOCATION

외부 데이터의 파일의 위치를 지정

directory

파일을 찾을 디렉터리를 의미하며, 지정하지 않으면 디폴트 디렉터리에서 파일을 찾게 됨

location_specifier

문자열 디렉터리로부터 파일까지의 경로 및 파일명을 지정

- index_org_table_clause

구성요소
설명

iot_attr

Index organized table을 생성할 때 사용하는 속성을 설정할 경우 사용

INCLUDING

인덱스 블록에 primary key와 함께 저장할 수 있는 컬럼을 의미

OVERFLOW

primary key를 제외하고 인덱스 블록 외에 별도로 데이터 저장을 원할 경우 사용

- iot_attr

구성요소
설명

PCTTHRESHOLD

인덱스 블록에서 최대로 사용할 수 있는 사이즈를 의미 (단위: 퍼센트(%))

- table_properties

구성요소
설명

colprop

컬럼별로 대용량 객체형 데이터 타입이 저장되는 방식을 설정

table_partitioning_clause

  • 파티션 테이블을 생성하기 위한 문법

  • RANGE 파티셔닝, LIST 파티셔닝, HASH 파티셔닝 및 RANGE 복합 파티셔닝, LIST 복합 파티셔닝을 지원

  • 파티션 또는 서브 파티션마다 서로 다른 물리적인 속성을 지정할 수 있음

  • 단, LONG 또는 LONG RAW 데이터 타입을 가진 테이블은 파티셔닝할 수 없으며, 파티션 키 컬럼으로 대용량 객체형 데이터 타입, ROWID 데이터 타입의 컬럼은 사용할 수 없음

  • 파티션에 대한 자세한 내용은 “Tibero 관리자 안내서”를 참고

parallel_clause

테이블 생성 과정을 병렬적으로 수행하며, 테이블에 수행하는 DML의 기본 DOP(Degree of Parallelism)으로 사용됨

atbl_con_alterstate_cl

제약조건의 상태를 변경할 때 사용

AS subquery

부질의를 통해 테이블의 컬럼 정의와 데이터를 옮김

- colprop

구성요소
설명

colname

대용량 객체형 데이터 타입이 저장되는 방식을 설정할 컬럼의 이름을 명시

lob_sgmt_param

대용량 객체형 데이터 타입의 저장 방법을 지정

lob_name

대용량 객체형 데이터 타입의 이름을 설정

- lob_param

구성요소
설명

TABLESPACE

대용량 객체형 데이터 타입이 저장되는 세그먼트의 테이블 스페이스를 지정할 수 있음

ENABLE STORAGE IN ROW

약 4000bytes 이하의 작은 크기의 대용량 객체형은 LOB 세그먼트를 만들어 저장하지 않고 일반 컬럼처럼 로우의 데이터 안에 함께 저장(기본값)

DISABLE STORAGE IN ROW

대용량 객체형 데이터의 크기에 상관없이 LOB 세그먼트에 저장

ENCRYPT

대용량 객체형 데이터의 내용을 암호화하여 저장

DECRYPT

대용량 객체형 데이터의 내용을 암호화하지 않고 저장

- lob_compression_clause

구성요소
설명

NOCOMPRESS

  • 대용량 객체형 LOB 데이터에 대한 압축을 수행하지 않음

  • 별도로 지정 하지 않으면 기본 설정

COMPRESS

  • 대용량 객체형 LOB 데이터에 대한 압축을 수행

  • 옵션을 명시하지 않 은 경우 MEDIUM 설정으로 압축이 수행됨

COMPRESS LOW

  • 대용량 객체형 LOB 데이터에 대한 압축을 수행

  • 가장 낮은 압축률과 가장 빠른 속도로 압축을 함

COMPRESS MEDIUM

  • 대용량 객체형 LOB 데이터에 대한 압축을 수행

  • 중간 정도의 압축률 과 중간정도의 속도로 압축을 함

COMPRESS HIGH

  • 대용량 객체형 LOB 데이터에 대한 압축을 수행

  • 가장 높은 압축률과 가장 느린 속도로 압축을 함

subpartition에는 compress 옵션을 지원하지 않습니다.

– lob_deduplicate

구성요소
설명

KEEP_DUPLICATES

대용량 객체형 데이터 타입이 저장되는 세그먼트 중복된 데이터를 허용

DEDUPLICATE

  • 대용량 객체형 데이터 타입이 저장되는 세그먼트 중복된 데이터를 허용 하지 않고 제거

  • 같은 데이터는 한개의 카피만 가지고 있음

subpartition에는 KEEP_DUPLICATES / DEDUPLICATE 옵션을 지원하지 않습니다. partitioned table의 경우 모든 파티션에 deduplicate 기능을 적용해야 합니다.

- table_partitioning_clause

구성요소
설명

range_partitions

테이블을 파티션 키 컬럼 값의 범위에 따라 나눔

list_partitions

테이블을 파티션 키 컬럼 값의 목록에 따라 나눔

hash_partitions

테이블을 파티션 키 컬럼 값을 해싱한 결과에 따라 나눔

composite_range_partitions

RANGE 파티션으로 나누어진 파티션을 한 번 더 파티셔닝하여 복합 RANGE 파티션 테이블을 생성

composite_list_partitions

LIST 파티션으로 나누어진 파티션을 한 번 더 파티셔닝하여 복합 LIST 파티션 테이블을 생성

composite_hash_partitions

HASH 파티션으로 나누어진 파티션을 한 번 더 파티셔닝하여 복합 HASH 파티션 테이블을 생성

- range_partitions

구성요소
설명

column

  • 파티션의 기준이 되는 파티션 키 컬럼을 설정

  • 로우가 어떤 파티션에 포함될지는 해당 로우가 가지고 있는 이 컬럼의 값에 따라 결정됨

interval_value

  • Range 파티션의 Interval 값을 지정

  • Interval 값이 지정된 Range 파티션으로의 DML을 수행하는 경우 파티션 키 값에 대응되는 파티션이 존재하지 않을 때, 새로운 파티션을 생성하여 DML 수행을 계속

  • 이때 새로 생성되는 파티션의 경계값을 계산하기 위해 필요한 값이 interval_value

  • Range 파티션의 마지막 파티션의 경계값을 시작으로 Interval 값의 배수를 더한 값을 새로 만들어질 파티션의 경계값으로 갖게 됨

range_values_clause

  • 파티션의 상위 경계 값(Upper bound)을 지정

  • 지정한 값은 해당 파티션에 포함되지 않으며, 경계 값의 개수는 파티셔닝 컬럼의 개수와 동일해야 함

  • 최댓값을 표현하고자 할 때는 MAXVALUE 예약어를 사용

  • MAXVALUE를 사용하면, NULL 값을 포함하여 이전 파티션보다 해당 컬럼의 값이 큰 모든 로우가 해당 파티션으로 들어감

- list_partitions

구성요소
설명

column

  • 파티션의 기준이 되는 파티션 키 컬럼을 설정

  • 로우가 어떤 파티션에 포함될지는 해당 로우가 가지고 있는 이 컬럼의 값에 따라 결정됨

  • LIST 파티션에서는 컬럼을 한 개만 지정할 수 있다는 점이 다른 파티션과 다름

list_values_clause

  • 파티션에 포함될 로우의 파티션 컬럼 값을 지정

  • 즉 파티셔닝 컬럼의 값이 지정한 값과 같은 로우가 해당 파티션으로 포함됨

  • NULL 예약어를 사용하여 NULL 값을 가지는 로우를 지정할 수 있음

  • RANGE 파티션의 MAXVALUE와 유사하게, LIST 파티션에서는 DEFAULT 예약어를 사용하여 다른 파티션에 들어가지 않는 모든 로우를 포함하는 파티션을 지정할 수 있음

  • 단, DEFAULT 값은 다른 값과 같이 쓸 수 없으며, 맨 마지막 파티션에만 사용할 수 있음

- hash_partitions

구성요소
설명

column

  • 파티션의 기준이 되는 파티션 키 컬럼을 설정

  • 로우가 어떤 파티션에 포함될 지는 해당 로우가 가지고 있는 이 컬럼의 값 에 따라 결정됨

hash_partition_desc

HASH 파티션의 세부적인 속성을 지정

hash_partitions_by_quantity

HASH 파티션을 파티션 개수와 테이블 스페이스만 지정함으로써 간단하게 생성할 수 있도록 해 주는 문법

- composite_range_partitions

구성요소
설명

subpartition_by_clause

  • RANGE 파티션을 다시 파티셔닝을 할 방법을 설정

  • 기본 파티셔닝과 마찬가지로 RANGE, LIST, HASH 중에 선택할 수 있으며, 서브 파티셔닝 컬럼을 지정

range_partition_desc

복합 RANGE 파티션의 세부적인 속성을 지정

- composite_list_partitions

구성요소
설명

subpartition_by_clause

  • LIST 파티션을 다시 파티셔닝을 할 방법을 설정

  • 기본 파티셔닝과 마찬가지로 RANGE, LIST, HASH 중에 선택할 수 있으며, 서브 파티셔닝 컬럼을 지정

list_partition_desc

복합 LIST 파티션의 세부적인 속성을 지정

- composite_hash_partitions

구성요소
설명

subpartition_by_clause

  • HASH 파티션을 다시 파티셔닝을 할 방법을 설정

  • 기본 파티셔닝과 마찬가지로 RANGE, LIST, HASH 중에 선택할 수 있으며, 서브 파티셔닝 컬럼을 지정

hash_partition_desc

HASH 파티션의 세부적인 속성을 지정

hash_partitions_by_quantity

HASH 파티션을 파티션 개수와 테이블 스페이스만 지정함으로써 간단하게 생성할 수 있도록 해 주는 문법

- subpartition_by_clause

구성요소
설명

RANGE

서브 파티션의 파티셔닝 방법을 RANGE 파티션으로 설정

LIST

서브 파티션의 파티셔닝 방법을 LIST 파티션으로 설정

HASH

서브 파티션의 파티셔닝 방법을 HASH 파티션으로 설정

column

파티션의 기준이 되는 파티션 키 컬럼을 설정

subpartition_template

서브 파티션의 속성을 모든 파티션에 적용시킬때 사용

- subpartition_template

구성요소
설명

SUBPARTITION TEMPLATE

서브 파티션의 속성을 모든 파티션에 적용시킬 때 사용하는 구문

list_subpartition_desc

  • 서브 파티션의 세부적인 속성을 지정

  • 서브 파티션이라는 점과 예약어가 SUBPARTITION, SUBPARTITIONS로 바뀐 것 외에 다른 문법은 기본 파티셔닝과 동일

hash_subpartitions_by_quantity

HASH 서브 파티션을 파티션의 개수와 테이블 스페이스만 지정함으로써 간단하게 생성할 수 있도록 해 주는 문법

- range_partition_desc

구성요소
설명

PARTITION partition_name

파티션의 이름을 지정

range_values_clause

  • 파티션의 상위 경계 값(Upper bound)을 지정

  • 지정한 값은 해당 파티션에 포함되지 않으며, 경계 값의 개수는 파티셔닝 컬럼의 개수와 동일해야 함

  • 최댓값을 표현하고자 할 때는 MAXVALUE 예약어를 사용함

  • MAXVALUE를 사용하면, NULL 값을 포함하여 이전 파티션보다 해당 컬럼의 값이 큰 모든 로우가 해당 파티션으로 들어감

table_partition_desc

  • 파티션의 물리적인 속성을 지정

  • 문법은 테이블의 속성을 지정할 때와 유사하며, 파티션의 속성을 지정합니다는 것만 다름

range_subpartition_desc

  • 서브 파티션의 세부적인 속성을 지정

  • 서브 파티션이라는 점과 예약어가 SUBPARTITION, SUBPARTITIONS로 바뀐 것 외에 다른 문법은 기본 파티셔닝과 동일

list_subpartition_desc

  • 서브 파티션의 세부적인 속성을 지정

  • 서브 파티션이라는 점과 예약어가 SUBPARTITION, SUBPARTITIONS로 바뀐 것 외에 다른 문법은 기본 파티셔닝과 동일

hash_subparrition_desc

  • 서브 파티션의 세부적인 속성을 지정

  • 서브 파티션이라는 점과 예약어가 SUBPARTITION, SUBPARTITIONS 로 바뀐 것 외에 다른 문법은 기본 파티셔닝과 동일

hash_subparrition_by_quantity

HASH 서브 파티션을 파티션의 개수와 테이블 스페이스만 지정함으로 써 간단하게 생성할 수 있도록 해 주는 문법

– list_partition_desc

구성요소
설명

PARTITION partition_name

파티션의 이름을 지정

list_values_clause

  • 파티션에 포함될 로우의 파티션 컬럼 값을 지정

  • 즉 파티셔닝 컬럼의 값이 지정한 값과 같은 로우가 해당 파티션으로 포함됨

  • NULL 예약어를 사용하여 NULL 값을 가지는 로우를 지정할 수 있음

  • RANGE 파티션의 MAXVALUE와 유사하게, LIST 파티션에서는 DEFAULT 예약어를 사용하여 다른 파티션에 들어가지 않는 모든 로우를 포함하는 파티션을 지정할 수 있음

  • 단, DEFAULT 값은 다른 값과 같이 쓰일 수 없으며, 맨 마지막 파티션에만 사용할 수 있음

table_partition_desc

  • 파티션의 물리적인 속성을 지정

  • 문법은 테이블의 속성을 지정할 때와 유사하며, 파티션의 속성을 지정합니다는 것만 다름

range_subpartition_desc

  • 서브 파티션의 세부적인 속성을 지정

  • 서브 파티션이라는 점과 예약어가 SUBPARTITION, SUBPARTITIONS로 바뀐 것 외에 다른 문법은 기본 파티셔닝과 동일

  • 자세한 문법은 range_partition_desc를 참고

list_subpartition_desc

  • 서브 파티션의 세부적인 속성을 지정

  • 서브 파티션이라는 점과 예약어가 SUBPARTITION, SUBPARTITIONS로 바뀐 것 외에 다른 문법은 기본 파티셔닝과 동일

  • 자세한 문법은 list_partition_desc를 참고

hash_subpartition_desc

Tibero InfiniData에서는 지원하지 않음

hash_subpartition_desc

  • 서브 파티션의 세부적인 속성을 지정

  • 서브 파티션이라는 점과 예약어가 SUBPARTITION, SUBPARTITIONS로 바뀐 것 외에 다른 문법은 기본 파티셔닝과 동일

  • 자세한 문법은 hash_partition_desc를 참고

hash_subpartition_by_quantity

Tibero에서는 지원하지 않음

hash_subparrition_by_quantity

HASH 서브 파티션을 파티션의 개수와 테이블 스페이스만 지정함으로써 간단하게 생성할 수 있도록 해 주는 문법

- hash_partition_desc

구성요소
설명

PARTITION partition_name

  • 파티션의 이름을 지정

  • 생략하면 시스템이 자동으로 생성

table_partition_desc

  • 파티션의 물리적인 속성을 지정

  • 문법은 테이블의 속성을 지정할 때와 유사하며, 파티션의 속성을 지정합니다는 것만 다름

- hash_partition_by_quantity

구성요소
설명

PARTITIONS unsigned_integer

생성할 파티션의 개수를 지정

STORE IN tablespace

  • 파티션이 위치할 테이블 스페이스를 지정

  • 테이블 스페이스를 지정한 개수가 파티션의 개수와 일치할 필요는 없으며, 개수가 서로 다를 경우 라운드 로빈(Round-robin) 방식으로 테이블 스페이스가 차례대로 지정됨

- range_subpartition_desc

구성요소
설명

subpartition_name

  • 서브 파티션의 이름을 명시

  • 생략하면 시스템이 자동으로 생성

range_values_clause

RANGE 파티션의 경계 값을 지정

table_partition_desc

  • 파티션의 물리적인 속성을 지정

  • 문법은 테이블의 속성을 지정할 때와 유사하며, 파티션의 속성을 지정합니다는 것만 다름

- list_subpartition_desc

구성요소
설명

subpartition_name

  • 서브 파티션의 이름을 명시

  • 생략하면 시스템이 자동으로 생성

list_values_clause

LIST 파티션의 분류 값을 지정

table_partition_desc

  • 파티션의 물리적인 속성을 지정

  • 문법은 테이블의 속성을 지정할 때와 유사하며, 파티션의 속성을 지정합니다는 것만 다름

- hash_subpartition_desc

구성요소
설명

subpartition_name

  • 서브 파티션의 이름을 명시

  • 생략하면 시스템이 자동으로 생성

table_partition_desc

  • 파티션의 물리적인 속성을 지정

  • 문법은 테이블의 속성을 지정할 때와 유사하며, 파티션의 속성을 지정합니다는 것만 다름

  • hash_subpartition_by_quantity

구성요소
설명

SUBPARTITIONS unsigned_integer

생성할 서브 파티션의 개수를 지정

STORE IN tablespace

  • 서브 파티션이 위치할 테이블 스페이스를 지정

  • 테이블 스페이스를 지정한 개수가 서브 파티션의 개수와 일치할 필요는 없으며, 개수가 서로 다를 경우 라운드 로빈 방식으로 테이블 스페이스가 차례대로 지정됨

- range_value_clause

구성요소
설명

literal

  • 파티션의 상위 경계 값을 지정

  • 지정한 값은 해당 파티션에 포함되 지 않으며, 경계 값의 개수는 파티셔닝 컬럼의 개수와 동일해야 함

MAXVALUE

  • 최댓값을 표현하고자 할 때는 MAXVALUE를 사용

  • MAXVALUE를 사용하면 NULL 값을 포함하여 이전 파티션보다 해당 컬럼의 값이 큰 모든 로우가 해당 파티션으로 들어감

- list_value_clause

구성요소
설명

literal

  • 파티션에 포함될 로우의 파티션 컬럼 값을 지정

  • 즉 파티셔닝 컬럼 의 값이 지정한 값과 같은 로우가 해당 파티션으로 들어감

NULL

NULL 예약어를 사용하여 NULL 값을 가지는 로우를 지정할 수 있음

DEFAULT

  • DEFAULT 예약어를 사용하여 다른 파티션에 들어가지 않는 모든 로우 를 포함하는 파티션을 지정할 수 있음

  • 단, DEFAULT 값은 다른 값과 같이 쓰일 수 없으며, 맨 마지막 파티션에만 사용할 수 있음

- table_partition_desc

구성요소
설명

sgmt_attr

sgmt_attr 관련 문법은 “Sgmt_attr”을 참고

table_compression

테이블의 압축 여부를 지정

colprop

컬럼별로 대용량 객체형 데이터 타입이 저장되는 방식을 설정

- atbl_con_alterstate_cl

구성요소
설명

ENABLE/DISABLE VALIDATE/NOVALIDATE

  • 테이블을 생성하면서 이 부분을 지정하지 않으면, 디폴트는 모든 제약 조건을 ENABLE VALIDATE 상태로 설정

  • 자세한 내용은 “제약조건”을 참고

PRIMARY KEY

테이블에 기본 키 제약조건이 이미 존재하는 경우 이를 활성화 또는 비활성화할 수 있음

UNIQUE column_name

뒤에 명시하는 column_name에 이미 유일 키 제약조건이 존재하는 경우 이를 활성화 또는 비활성화할 수 있음

CONSTRAINT name

해당 제약조건의 이름을 명시하여 이미 존재하는 제약조건을 활성화 또는 비활성화할 수 있음

CASCADE

  • 다른 테이블이나 같은 테이블의 다른 컬럼으로부터 FOREIGN KEY 제약조건으로 참조되는 기본 키나 유일 키 제약조건을 비활성화할 때 관련된 FOREIGN KEY까지 함께 비활성화하기 위해 사용

  • FOREIGN KEY가 존재하는 제약조건을 비활성화하는 경우에는 반드시 포함되어야 함

KEEP INDEX

  • 제약조건을 비활성화하면서 제약조건에서 사용하는 인덱스를 제거하지 않고 그냥 유지하고자 할 때 명시

  • 기본값이므로 생략할 수 있음

DROP INDEX

  • 기본 키, 유일 키, FOREIGN KEY 같은 인덱스를 사용하는 제약조건을 제거하려 할 때 인덱스를 함께 제거하고자 할 때 명시

  • 생략하면 KEEP INDEX로 인식됨

using_index_clause

“제약조건”을 참고

  • 예제

– create_table

다음은 제약조건과 기본값을 포함한 일반 테이블을 생성하는 예입니다.

다음은 TEMPORARY를 명시하여 임시 테이블을 생성하는 예입니다.

– physical_properties

다음은 sgmt_attr을 사용해 테이블을 생성하는 예입니다.

다음은 ORGANIZATION EXTERNAL을 명시해 외부 테이블을 생성하는 예입니다.

DIRECTORY 생성에 관한 내용은 "CREATE DIRECTORY" 를 참고합니다.

– table_properties

다음은 as_subquery를 포함한 테이블을 생성하는 예입니다.

다음은 colprop를 포함한 테이블을 생성하는 예입니다.

– table_partitioning_clause

다음은 range_partitions를 명시해 RANGE 파티션을 생성하는 예입니다.

다음은 list_partitions를 명시해 LIST 파티션을 생성하는 예입니다.

다음은 hash_partitions를 명시해 HASH 파티션을 생성하는 예입니다.

다음은 composit_range_partitions를 명시해 복합 RANGE 파티션을 생성하는 예입니다.

– atbl_con_alterstate_cl

다음은 atbl_con_alterstate_cl를 사용해 테이블의 제약조건을 활성화하거나 비활성화하는 등의 설 정을 하는 예입니다.

hashtag
CREATE TABLESPACE

테이블 스페이스를 생성합니다. 테이블 스페이스는 테이블, 인덱스 등의 스키마 객체를 저장하는 물리적, 논 리적 공간입니다.

CREATE TABLESPACE의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

    • SYSDBA 특권이 있어야 CREATE TABLESPACE 문을 실행할 수 있습니다.

  • 구성요소

– create_tablespace

구성요소
설명

BIGFILE

단일 대용량 데이터 파일인 BIGFILE 테이블 스페이스를 생성하도록 함

identifier

생성할 테이블 스페이스의 이름을 명시

dfspec

  • 파일의 이름, 파일의 크기 등과 관련된 설정을 할 수 있음

  • 자세한 내용은 “CREATE DATABASE”를 참고

  • 일반 TABLESPACE의 경우 최대 32GB까지, BIGFILE TABLESPACE의 경 우 최대 32TB 크기까지 데이터 파일 크기를 지정할 수 있음

  • 또한, 일반 TA BLESPACE는 여러 개의 데이터 파일을 지정할 수 있지만, BIGFILE TA BLESPACE는 하나의 데이터 파일만 지정할 수 있음

extspec_clause

테이블 스페이스의 익스텐트가 어떻게 관리될 것인지를 명시

  • extspec_clause

구성요소
설명

EXTENT_MANAGEMENT_LOCAL

EXTENT_MANAGEMENT_LOCAL의 뒷 부분에 테이블 스페이스의 익스텐트가 어떻게 관리될 것인지를 명시

AUTOALLOCATE

익스텐트의 크기를 시스템이 자동으로 설정

UNIFORM

  • 익스텐트의 크기를 사용자가 설정

  • 사용자가 설정한 크기대로 익스텐트가 항상 일정한 크기로 생성됨

size

  • 익스텐트의 블록 크기를 명시

  • $TB_SID.tip 파일에 설정된 DB_BLOCK_SIZE 파라미터의 값이 블록 크기의 배수가 아니면, 블록 크기 단위로 내림 계산됨(기본값: 16개 블록 크기, 16 ~ 4194304까지의 블록 개수만큼의 크기 명시)

- encryption_clause

테이블 스페이스를 암호화하고 싶을 때 사용합니다.

구성요소
설명

encryption_spec

암호화 알고리즘을 선택

USING 뒤에 암호화 알고리즘을 작은따옴표와 함께 적는 방식으로 지정

지원하는 암호화 알고리즘은 다음과 같음

  • 3DES168

  • AES128 (기본값)

  • AES192

  • AES256

  • ARIA128

  • ARIA192

  • ARIA256

  • GOST

  • SM4

자세한 사용법은 "Tibero 관리자 안내서"를 참고

  • 예제

다음은 CREATE TABLESPACE를 사용해 테이블 스페이스를 생성하는 예입니다.

hashtag
CREATE TRIGGER

데이터베이스 트리거를 생성합니다. 트리거는 테이블, 스키마, 데이터베이스와 연결된 tbPSM 블록입니다.

트리거는 활성화 상태로 생성되며, 생성 이후에 ALTER TRIGGER 문 또는 ALTER TABLE 문을 사용하여 활성화 또는 비활성화 상태를 변경할 수 있습니다. 트리거가 활성화된 상태에서는 주어진 조건이 만족되는 순 간, 트리거의 내용이 수행됩니다.

트리거에 컴파일 에러가 발생하면 트리거는 생성되지만, 실행은 되지 않습니다. 결과적으로 트리거가 비활 성화 상태로 바뀌거나, 컴파일 에러가 없는 버전으로 교체되거나, 트리거가 삭제되기 전까지는 트리거 조 건을 만족하는 모든 DML 문장이 블록되는 상태가 됩니다. DDL 또는 DB 이벤트 트리거를 사용하기 위해서 는 파라미터 _DDL_TRIGGER_ENABLE을 Y로 켜야 합니다.

CREATE TRIGGER의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

    • 사용자가 소유한 스키마에 트리거를 생성하려면, CREATE TRIGGER 시스템 특권이 있어야 합니다.

    • 다른 사용자가 소유한 스키마에 트리거를 생성하려면, CREATE ANY TRIGGER 시스템 특권이 있어 야 합니다.

    • 데이터베이스에 연결되는 트리거를 생성하기 위해서는 ADMINISTER DATABASE TRIGGER 시스 템 특권이 있어야 합니다.

    • 트리거가 SQL 문장을 수행하거나 프러시저 또는 함수를 호출할 때 트리거의 소유자는 이러한 작업 을 수행할 수 있는 특권이 있어야 합니다.

  • 구성요소

    • create_trigger

구성요소
설명

OR REPLACE

이미 존재하는 트리거의 내용을 변경할 때 OR REPLACE를 명시

not_exist

IF NOT EXISTS 해당 옵션을 명시하면

  • 동일한 이름의 OBJECT가 이미 존재하는 경우에도 에러 로그를 발생시키지 않고 성공 메시지를 반환

  • OBJECT가 존재하지 않는 경우에는 기존 CREATE 문과 동일하게 동작

  • OR REPLACE와 같이 사용할 수 없음

execute_type

트리거가 작동이 되는 실행 종류를 명시

BEFORE

  • BEFORE를 명시하면 트리거를 동작시킬 수 있는 이벤트를 수행하기 전에 트리거를 먼저 수행

  • 로우 트리거의 경우 해당 로우가 변경되기 전에 트리거가 먼저 수행됨

AFTER

  • AFTER는 BEFORE와 반대로 트리거를 동작시킬 수 있는 이벤트를 먼저 수행하고 트리거를 나중에 수행

  • 로우 트리거의 경우 해당 로우를 변경한 후 트리거를 수행하게 됨

INSTEAD OF

  • INSTEAD OF는 트리거를 수행하는 대신 트리거를 수행

  • 뷰에 대한 DML 이벤트의 경우에만 가능하며, 테이블에 대한 경우 또는 DDL이나 DB 이벤트일 경우에는 사용할 수 없음

dml_event_clause

  • 트리거를 DML 이벤트 트리거로 만듦

  • DML 이벤트 트리거는 지정한 DML 문장이 실행될 때마다 트리거가 수행됨

ddl_db_event_clause

  • 트리거를 DDL 또는 DB 이벤트 트리거로 만듦

  • DML 이벤트 트리거는 지정한 DDL 문장 또는 DB 이벤트가 실행될 때마다 트리거가 수행됨

FOLLOWS trigger_name

  • 현재 트리거를 반드시 지정한 트리거(trigger_name) 이후에 실행하도록 지정

  • 지정하지 않을 경우 트리거는 생성된 순서대로 실행됨

enable_option

  • 트리거 활성화 여부를 지정

  • ENABLE 또는 DISABLE을 사용할 수 있으며, 기본값은 활성화(ENABLE)

WHEN condition_expression

  • 트리거가 동작할 조건을 명시

  • 이 조건이 만족되기 전까지는 데이터베이스는 트리거를 동작시키지 않음

  • 만일 DML 이벤트 트리거에 이 조건을 명시한 경우에는, 반드시 FOR EACH ROW를 함께 명시하여야 함

psm_source

  • 트리거가 동작할 때 수행될 프러시저를 명시

  • tbPSM 블록을 직접 명시하는 방법

call_spec

  • 트리거가 동작했을 때 수행될 프러시저를 명시

  • CALL 문을 사용해 저장된 프러시저를 호출

  • 자세한 내용은 “CALL”을 참고

– dml_event_clause

구성요소
설명

dml_event_type

dml_event_type에 설정된 DML 문장이 실행될 때마다 트리거가 수행되 도록 설정

ON schema

  • 생성된 트리거가 연결될 스키마를 명시

  • 생략하면 현재 사용자의 스키마로 인식됨

object_name

트리거를 연결할 객체의 이름을 명시

REFERENCING refer ence_clause

  • 트리거에서 현재 테이블의 로우의 값에 접근하는 방법을 지정

  • 트리거에서 현재 테이블의 로우의 값에 접근할 때 기존 값은 OLD, 새 값은 NEW로 접근하게 됨

  • 예를 들어 테이블에 A라는 컬럼이 있습니다면 새 값을 지정하려고 할 때 트리거 내의 PSM 코드에서 다음과 같이 명시 할 수 있음

  • 사용자의 필요에 따라 NEW, OLD가 아닌 다른 이름으로 현재 로우의 값에 접근하고 싶다면 이 절을 이용해 바꾸어 줄 수 있음 :OLD.A := 1;

FOR EACH ROW

  • FOR EACH ROW를 명시하면 트리거는 로우 트리거가 됨

  • 트리거 이벤트에 영향을 받는 각각의 로우에 로우 트리거를 수행

  • 이 절을 생략하면, 트리거는 문 단위의 트리거가 됨

  • 트리거 이벤트를 발생시키는 SQL 문장이 수행되면, 트리거는 한 번만 수행됨

- dml_event_type

구성요소
설명

DELETE

테이블에서 DELETE 문이 수행되어 로우가 삭제될 때마다 트리거가 수행됨

INSERT

테이블에 INSERT 문이 수행되어 로우가 추가될 때마다 트리거가 수행됨

UPDATE

테이블에 저장된 값이 변경될 때마다 트리거가 수행됨

UPDATE OF

OF에 명시된 컬럼의 값이 변경될 때마다 트리거를 수행

- reference_clause

구성요소
설명

OLD

테이블의 로우의 기존 값에 접근할 때 사용됨

NEW

테이블의 로우의 새 값에 접근할 때 사용됨

AS identifier

OLD와 NEW 대신 다른 이름으로 지칭하고 싶을 때 사용

- ddl_db_event_clause

구성요소
설명

event

DDL 또는 DB 이벤트를 명시

on_type

  • DDL 또는 DB 이벤트가 일어난 대상을 명시

  • Schema 또는 Database 가 있음

- ddl_or_db_event

구성요소
설명

ALTER

DDL ALTER가 일어날 때 트리거가 수행

ANALYZE

DDL ANALYZE가 일어날 때 트리거가 수행

ASSOCIATE STATISTICS

DDL ASSOCIATE STATISTICS가 일어날 때 트리거가 수행.

AUDIT

DDL AUDIT이 일어날 때 트리거가 수행

COMMENT

DDL COMMENT가 일어날 때 트리거가 수행

CREATE

DDL CREATE가 일어날 때 트리거가 수행

DISASSOCIATE STATISTICS

DDL DISASSOCIATE STATISTICS가 일어날 때 트리거가 수행

DROP

DDL DROP이 일어날 때 트리거가 수행.

GRANT

DDL GRANT가 일어날 때 트리거가 수행

NOAUDIT

DDL NOAUDIT이 일어날 때 트리거가 수행

RENAME

DDL RENAME이 일어날 때 트리거가 수행

REVOKE

DDL REVOKE가 일어날 때 트리거가 수행

TRUNCATE

DDL TRUNCATE가 일어날 때 트리거가 수행

DDL

어떠한 DDL이 일어날 때 트리거가 수행

SERVERERROR

EVENT SERVERERROR가 일어날 때 트리거가 수행

LOGON

EVENT LOGON이 일어날 때 트리거가 수행

LOGOFF

EVENT LOGOFF가 일어날 때 트리거가 수행

STARTUP

EVENT STARTUP이 일어날 때 트리거가 수행

SHUTDOWN

EVENT SHUTDOWN이 일어날 때 트리거가 수행

SUSPEND

EVENT SUSPEND가 일어날 때 트리거가 수행

  • 예제

다음은 CREATE TRIGGER를 사용해 트리거를 생성하는 예입니다.

다음은 CREATE TRIGGER를 사용해 DDL 트리거를 생성하는 예입니다.

hashtag
CREATE TYPE

사용자 정의 타입을 새로 정의하거나 기존의 사용자 정의 타입으로 대체합니다. 사용자 정의 타입은 tbPSM

타입으로 사용가능하며, Tibero 서버에서 저장됩니다.

CREATE TYPE의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

    • 사용자가 자신의 스키마에 사용자 정의 타입을 생성하고자 하면 CREATE TYPE 시스템 특권을 부여 받아야 합니다.

    • 다른 사용자의 스키마에 사용자 정의 타입을 생성하거나 변경하고자 하면, CREATE ANY TYPE 또 는 ALTER ANY TYPE 시스템 특권을 부여받아야 합니다.

  • 구성요소

    • create_type

구성요소
설명

OR REPLACE

  • 이미 존재하는 사용자 정의 타입을 다시 정의하고자 할 때 사용

  • OR REPLACE가 포함되면 해당 타입을 재컴파일

  • 사용자 정의 타입을 제거하고 다시 생성하는 것과의 차이는 OR REPLACE를 이용하면 해당 타입에 기존의 특권이 그대로 유지된다는 점

schema

  • 사용자 정의 타입이 속해 있는 스키마를 명시

  • 생략하면 현재 사용자의 스키마로 인식됨

type_name

생성하고자 하는 사용자 정의 타입의 이름을 명시

oid_clause

현재 버전에서는 아무런 의미도 없음

IS

  • IS나 AS는 기호에 맞게 선택할 수 있으며, 둘의 차이는 없음

  • IS 다음에는 타입의 본문이 옴

AS

IS와 동일합니다. AS 다음에는 타입의 본문이 옴

VARYING ARRAY

  • 생성할 사용자 정의 타입의 배열임을 지정

  • VARRAY와 동일

VARRAY

  • 생성할 사용자 정의 타입의 배열임을 지정

  • VARYING ARRAY와 동일

unsigned_integer

배열의 최대 길이를 지정하는 양수

TABLE

생성할 사용자 정의 타입이 네스티드 테이블임을 지정.

element_datatype

  • 구성 요소의 데이터 타입

  • 구성 요소의 데이터 타입은 tbPSM에서 지원하는 모든 데이터 타입과 사용자 정의 데이터 타입이 가능

  • 데이터 타입의 문자열의 길이, 숫자의 정밀도와 스케일은 지정 가능

OBJECT

생성할 사용자 정의 타입의 오브젝트임을 지정

attribute_name

애트리뷰트 이름을 지정

attribute_datatype

  • 애트리뷰트의 데이터 타입

  • 구성 요소의 데이터 타입은 tbPSM에서 지원하는 모든 데이터 타입과 사용자 정의 데이터 타입이 가능

  • 데이터 타입의 문자열의 길이, 숫자의 정밀도와 스케일은 지정 가능

constructor_declaration

  • 생성자의 선언부

  • 리턴타입은 생성 타입과 동일하나, SELF AS RESULT로 표현

map_method_declaration

  • 맵 메소드의 선언부

  • 리턴 타입은 항상 스칼라타입이며 파라미터는 없거나, SELF를 유일하게 가짐

order_method_declaration

  • 오더 메소드의 선언부

  • 리턴 타입은 항상 숫자 타입이며 SELF를 제외하고 같은 타입의 파라미터를 유일하게 가짐

  • 선택적으로 SELF를 갖을 수 있음

normal_method_declaration

  • 메소드의 선언부로 함수나 서브 프로그램을 가짐

  • 선택적으로 SELF를 가질 수 있음

FINAL

추가 하위 타입의 생성 가능 여부(기본값: FINAL)

  • FINAL : 하위 타입을 생성할 수 없음

  • NOT FINAL : 하위 타입을 생성할 수 있음

INSTANTIABLE

개체 인스턴스의 구성 가능 여부(기본값: INSTANTIABLE)

  • INSTANTIABLE : 개체 인스턴스를 구성할 수 있음

  • NOT INSTANTIABLE : 기본 또는 사용자 정의 생성자를 생성할 수 없음

  • 예제

다음은 CREATE TYPE를 사용해 사용자 타입을 생성하는 예입니다.

hashtag
CREATE TYPE BODY

사용자 정의 타입의 바디를 정의합니다. 바디를 정의할수 있는 타입은 오브젝트 타입으로 제한됩니다.

CREATE TYPE BODY의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

    • 사용자가 자신의 스키마에 사용자 정의 타입 바디를 생성하고자 하면 CREATE TYPE 시스템 특권을 부여받아야 합니다.

    • 다른 사용자의 스키마에 사용자 정의 타입 바디를 생성하거나 변경하고자 하면, CREATE ANY TYPE 또는 ALTER ANY TYPE 시스템 특권을 부여받아야 합니다.

  • 구성요소

    • create_type

구성요소
설명

OR REPLACE

  • 이미 존재하는 사용자 정의 타입을 다시 정의하고자 할 때 사용

  • OR REPLACE가 포함되면 해당 타입을 재컴파일

  • 사용자 정의 타입을 제거하고 다시 생성하는 것과의 차이는 OR REPLACE를 이용하면 해당 타입에 기존의 특권이 그대로 유지된다는 점

schema

  • 바디를 생성하고자 하는 사용자 정의 타입이 속해 있는 스키마를 명시

  • 생략하면 현재 사용자의 스키마로 인식됨

type_name

바디를 생성하고자 하는 사용자 정의 타입의 이름을 명시

constructor_definition

  • 생성자 정의는 생성자 스펙과 선언들, 문장들로 구성되어 있음

  • 생성자의 스펙은 CREATE TYPE 문에 선언된 것과 동일해야 하며, 선언들과 문장은 PSM의 일반적인 경우와 동일

map_method_definition

  • 맵 메소드 정의는 생성자 스펙과 선언들, 문장들로 구성되어 있음

  • 맵 메소드 스펙은 CREATE TYPE 문과 선언된 것과 동일해야 하며, 선언들과 문장은 PSM의 일반적인 경우와 동일

order_method_definition

  • 오더 메소드 정의는 생성자 스펙과 선언들, 문장들로 구성되어 있음

  • 오더 메소드 스펙은 CREATE TYPE 문과 선언된 것과 동일해야 하며, 선언들과 문장은 PSM의 일반적인 경우와 동일

member_method_definition

  • 멤버 메소드 정의는 생성자 스펙과 선언들, 문장들로 구성되어 있음

  • 멤버 메소드 스펙은 CREATE TYPE 문과 선언된 것과 동일해야 하며, 선언들과 문장은 PSM의 일반적인 경우와 동일

  • 예제

다음은 CREATE TYPE BODY를 사용해 사용자 타입을 생성하는 예입니다.

hashtag
CREATE USER

새로운 사용자를 생성합니다.

참고

사용자의 정보를 변경하거나, 제거하기 위해서는 “ALTER USER” , “DROP USER”의 내 용을 참고합니다.

CREATE USER의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

    • 사용자를 생성하기 위해서는 CREATE USER 시스템 특권이 필요합니다.

    • CREATE USER로 생성한 사용자는 처음에 아무런 특권이 없는 상태입니다. 따라서 생성한 사용자로 접속하기 위해서는 CREATE SESSION 시스템 특권이 필요하고, 그 밖에도 해당 시스템 특권이 필요 합니다. 시스템 특권에 대한 자세한 내용은 “ GRANT”를 참고합니다.

  • 구성요소

    • create_user

구성요소
설명

not_exist

IF NOT EXISTS 해당 옵션을 명시하면

  • 동일한 이름의 OBJECT가 이미 존재하는 경우에도 에러 로그를 발생 시키지 않고 성공 메시지를 반환

  • OBJECT가 존재하지 않는 경우에는 기존 CREATE 문과 동일하게 동작

username

  • 생성할 사용자의 이름

  • 사용자의 이름은 VARCHAR 데이터 타입으로 저장되고 길이는 최대 30자까지 가능

  • 사용자의 이름은 전체 데이터베이스의 다른 사용자 또는 역할의 이름과 중복되면 안 됨

IDENTIFIED BY password

  • 생성한 사용자를 인증하기 위한 패스워드

  • 패스워드는 문자열로서 임의의 문자를 사용할 수 있음

  • 특수 문자를 쓰기 위해서는 따옴표(' 또는 ")를 사용해서 패스워드를 감싸야 함

  • 대소문자가 구분되는 패스워드를 이용하고 싶다면 작은따옴표(")로 패스워드를 감싸야 함

  • 초기화 파라미터 'USE_CASE_SENSITIVE_PASSWORD'를 'Y'로 설정할 경우 따옴표를 사용하지 않아도 기본적으로 대소문자를 구분하도록 패스워드가 생성됨

  • 길이는 최대 63자(ASCII 문자 기준)까지 가능

  • 특정 클라이언트나 데이터베이스 관리 프로그램에서 긴 패스워드를 지원하지 않을 수도 있으니, 패스워드는 될 수 있으면 20자 이내로 생성할 것을 권장

create_user_clause

생성한 사용자의 기본값을 설정하기 위한 부분으로 생략할 수 있음

– create_user_clause

구성요소
설명

DEFAULT TABLESPACE

  • 생성한 사용자가 사용할 디폴트 테이블 스페이스를 지정

  • 해당 테이블 스페이스는 미리 생성되어 있어야 함

  • DEFAULT TABLESPACE 부분을 생략하면, 자동으로 시스템 테이블 스페이스를 사용하게 됨

  • 하지만, 시스템 테이블 스페이스는 시스템 내부에서 사용하는 것이므로 될 수 있으면 별도의 테이블 스페이스를 만들어 사용할 것을 권장

  • 테이블 스페이스를 생성하는 방법은 “CREATE TABLESPACE”를 참고

PROFILE

사용자의 접속 및 패스워드 정책에 대한 프로파일을 지정

PASSWORD EXPIRE

사용자의 패스워드를 사용기간 만료 상태로 생성하여, 사용자가 처음 접속할 때 원하는 패스워드를 입력할 수 있도록 함

ACCOUNT LOCK

  • 사용자를 잠금 상태로 생성

  • 생략하면 사용자를 잠금해제 상태로 생성

ACCOUNT UNLOCK

사용자를 잠금해제 상태로 생성 (기본값)

  • 예제

– create_user

다음은 사용자를 생성하고, DEFAULT TABLESPACE 문장을 사용해 디폴트 테이블 스페이스를 설정하는 예입니다.

– create_user_clause

다음은 사용자를 생성하고, PASSWORD EXPIRE를 사용해 패스워드를 만료된 상태로 변경하는 예 입니다.

다음은 사용자를 생성하고, ACCOUNT LOCK을 사용해 사용자를 잠금 상태로 변경하는 예입니다.

hashtag
CREATE VIEW

사용자의 스키마 또는 지정된 다른 사용자의 스키마에 속한 뷰를 생성합니다.

circle-info

참고

뷰를 제거하기 위해서는 “DROP VIEW”의 내용을 참고합니다.

CREATE VIEW의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

    • 뷰를 생성하기 위해서는 사용자가 소유한 스키마에 속한 뷰이거나, CREATE ANY VIEW 시스템 특 권이 필요합니다.

    • 뷰를 포함하고 있는 스키마의 소유자는 뷰가 참조하는 모든 테이블과 뷰에 대해 SELECT, INSERT, UPDATE, DELETE 중 어느 하나가 가능하도록 해당 특권을 가지고 있어야 합니다. 각 문장에 대한 자 세한 내용은 각각 “SELECT”, “INSERT”, “UPDATE”, “DELETE”를 참고합니다.

  • 구성요소

    • create_view

구성요소
설명

OR REPLACE

  • 기존에 존재하는 뷰라면 제거하고 새롭게 뷰를 만듦

  • 뷰를 제거하고 나서 다시 생성하는 것과의 차이는 대상 뷰에 관련된 기존의 특권과 참조가 그대로 유지된다는 점

  • 단, 뷰를 정의하는 부질의가 기존과 동일합니다면 뷰를 재생성하지 않고 기존의 뷰를 그대로 사용

FORCE

  • 뷰가 참조하는 객체의 존재 여부, 참조하는 객체에 대한 권한과 관계없이 강제로 뷰를 생성

  • 뷰를 먼저 생성한 후에 뷰가 참조하는 객체를 생성하거나 권한을 부여함으로써 뷰를 사용할 수 있음

schema

  • 생성할 뷰를 포함하는 스키마의 이름

  • 생략하면 현재 사용자의 스키마로 인식됨

view_name

  • 생성할 뷰의 이름

  • 뷰의 이름은 VARCHAR 데이터 타입으로 저장되고, 길이는 최대 30자까지 가능

  • 뷰의 이름은 테이블과 같은 네임스페이스를 사용하므로 스키마 내의 다른 뷰, 공유 동의어, 테이블, 시퀀스, 패키지, 함수, 프러시저의 이름과 중복되면 안 됨

alias

  • 부질의에서 결과로 나온 표현식을 지정하는 별칭

  • 별칭은 VARCHAR 데이터 타입으로 저장되고, 길이는 최대 30자까지 가능

  • 별칭을 생략했을 경우 부질의의 결과로 나온 표현식이 단순한 컬럼명이라면 해당 컬럼명을 별칭으로 설정

  • 부질의의 결과 표현식이 단순한 컬럼명 이상이라면 반드시 별칭을 표시해 주어야 함

  • 뷰 컬럼의 개수는 부질의 결과 로우의 컬럼 개수와 동일해야 합니다. 별칭은 뷰에서 유일한 이름이어야 함

  • ROWID 컬럼을 출력하는 부질의에 대해서는 별칭을 반드시 설정해야 함

AS subquery

  • 뷰를 정의하는 부질의

  • 부질의를 설정하는 방법은 SELECT 문장과 같음

  • 자세한 내용은 “SELECT”를 참고

  • 뷰를 정의하는 부질의에는 다음과 같은 제약이 있음

  • 뷰를 정의하는 부질의 결과 컬럼으로 시퀀스를 사용할 수 없음

  • 뷰를 정의하는 부질의 결과 컬럼으로 ROWID, ROWNUM, 또는 LEVEL을 사용할 경우 별칭을 반드시 설정해야 함

  • 뷰를 정의하는 부질의 결과 컬럼에 애스터리스크(*)를 사용했다면 참조 테이블에 컬럼을 추가했을 때 추가된 컬럼이 뷰에 자동으로 추가되지는 않음

  • OR REPLACE를 설정해서 새로 만들어야 함

subquery_restriction

부질의로 정의되는 뷰의 속성을 지정

– subquery_restriction

구성요소
설명

WITH READ ONLY

  • 부질의에 의해 생성된 뷰를 읽기 전용으로 만들어 수정할 수 없도록 함

  • 이 뷰에 대해서는 질의만 가능

WITH CHECK OPTION

  • WITH CHECK OPTION이 명시된 뷰를 갱신할 때는 갱신되는 로우가 갱신 후에도 뷰에 의해 SELECT가 되는 경우에 한해서만 그 로우의 갱신이 허용

  • 조인 뷰의 경우는 조인 컬럼 및 반복되는 컬럼은 무조건 갱신이 불가능합니다는 제약조건이 추가

  • 삽입의 경우도 갱신과 마찬가지로 삽입하는 로우가 뷰에 의해 SELECT가 되어야 함

  • 하지만 이것은 기반 테이블이 하나일 경우에만 가능하며 조인 뷰의 경우에는 무조건 삽입이 불가능

  • 삭제의 경우는 삭제의 대상이 되는 키 보존 테이블이 반복되지 않으면 자체 조인을 형성하지 않기 때문에 삭제가 가능

  • 예제

– create_view

다음은 As subquery를 사용해 뷰를 정의하는 부질의의 결과 컬럼으로 시퀀스를 사용했을 때 발생하는 에러의 예입니다.

다음은 As subquery를 사용해 뷰를 정의하는 부질의의 결과 컬럼으로 ROWNUM을 사용할 때 별칭을 설정하지 않으면 에러가 발생하는 예입니다.

뷰를 정의하는 부질의의 결과 컬럼으로 ROWID, ROWNUM, 또는 LEVEL을 사용할 경우 반드시 별칭을 설정해야 합니다.

다음은 As subquery를 사용해 뷰를 생성할 때 별칭을 지정하지 않았을 경우의 예입니다.

위의 예에서 특이한 점은 뷰의 별칭을 지정하지 않았고, 부질의의 결과 컬럼으로 표현식(salary * 1000) 을 입력했다는 점입니다. 하지만, 부질의의 표현식에 별칭(salary_won)을 선언하였으므로 결과적으로 그 별칭을 따르게 됩니다. 따라서 결과적으로 옳은 표현입니다.

– subquery_restriction

다음은 WITH READ ONLY를 사용해 읽기 전용으로 뷰를 만드는 예입니다. 읽기 전용으로 생성된 뷰는 갱신될 수 없습니다.

다음은 WITH CHECK OPTION을 부여하고 만든 뷰입니다. 이렇게 생성된 뷰는 갱신할 때 CHECK OPTION을 통과해야 갱신을 할 수 있습니다.

갱신 가능한 뷰

갱신 가능한 뷰(Updatable View)는 뷰를 통해 참조 테이블에 삽입, 갱신, 제거를 가능하게 합니다. 갱신 가능 한 뷰를 통해 어떤 컬럼을 수정할 수 있는지를 알고 싶다면 정적 뷰 USER_UPDATABLE_COLUMNS을 참고합니다. 이 뷰는 갱신 가능한 뷰의 어떤 컬럼을 수정할 수 있는지에 관한 정보를 저장하고 있습니다.

다음은 두 개의 테이블의 조인으로 생성된 뷰입니다.

테이블 factory의 location은 CONTRACT_VIEW에서는 유일한 값을 갖지 않습니다. 즉, CONTRACT_VIEW의 로우가 factory의 로우와 1:1 대응이 되지 않습니다.

따라서 다음과 같이 CONTRACT_VIEW 뷰에 의해서 factory 테이블은 갱신될 수 없습니다.

hashtag

hashtag
DROP DATABASE LINK

데이터베이스 링크를 제거합니다.

circle-info

참고

데이터베이스 링크에 대한 자세한 내용은 "Tibero 관리자 안내서"를 참고합니다.

DROP DATABASE LINK의 세부 사항은 다음과 같습니다.

  • 문법

  • 특권

    • 사용자가 소유한 스키마에 있는 데이터베이스 링크를 제거할 때는 아무런 권한이 필요하지 않습니다.

    • 공유 데이터베이스 링크를 제거할 때는 DROP PUBLIC DATABASE LINK 시스템 특권이 있어야 한합니다.

  • 구성요소

구성요소
설명

PUBLIC

  • 공유 데이터베이스 링크를 제거하기 위해 PUBLIC 예약어를 사용

  • 생략하면 사용자 자신의 스키마에 있는 데이터베이스 링크를 제거

dblink_name

  • 제거할 데이터베이스 링크의 이름

  • 주의할 점은 데이터베이스 링크의 이름을 지정할 때 스키마를 지정할 수 없습니다는 것

  • 데이터베이스 링크에서는 점(.) 기호를 단순히 이름에 포함되는 한 문자로 인식

  • 따라서 다른 사용자의 스키마에 있는 데이터베이스 링크는 제거할 수 없음

  • 예제

다음은 DROP DATABASE LINK와 DROP PUBLIC DATABASE LINK를 사용하는 예입니다.

hashtag
DROP DIRECTORY

디렉터리 객체를 제거합니다.

circle-info

참고

디렉터리를 생성하기 위해서는 “CREATE DIRECTORY”의 내용을 참고합니다.

DROP DIRECTORY의 세부 사항은 다음과 같습니다.

  • 문법

  • 특권

    • 디렉터리를 제거하기 위해서는 DROP ANY DIRECTORY 시스템 특권이 필요합니다.

  • 구성요소

구성요소
설명

dir_name

제거할 디렉터리 객체의 이름입니다.

  • 예제

다음은 DROP DIRECTORY를 사용해 'tmp'라는 디렉터리를 제거하는 예입니다.

hashtag

hashtag
DROP DISKSPACE

디스크스페이스를 제거합니다.

DROP DISKSPACE의 세부 내용은 다음과 같습니다.

  • 문법

  • 구성요소

– drop_diskspace

구성요소
설명

diskspace_name

제거할 디스크스페이스의 이름을 명시

FORCE

디스크스페이스를 구성하는 모든 디스크의 디스크 헤더를 초기화해서 다시 마운트할 수 없도록 하기 위해 명시

INCLUDING CONTENTS

디스크스페이스의 모든 파일을 삭제하고 디스크스페이스를 제거

EXCLUDING CONTENTS

  • 디스크스페이스에 사용자 파일이 없는 경우에만 디스크스페이스를 제거

  • 사용자 파일이 있는 경우에는 오류가 발생

  • 제거 조건이 명시되지 않은 경우의 기본 동작

  • 예제

다음은 DROP DISKSPACE를 사용해 디스크스페이스를 제거하는 예입니다.

hashtag
DROP FUNCTION

사용자 함수를 제거합니다. 제거된 함수를 포함하는 뷰나 함수, 프러시저 등은 바로 무효화됩니다. 이렇게 무 효가 된 문장이나 함수, 프러시저를 실행하면 다시 컴파일을 시도하지만 이미 제거되었으므로 에러를 반 환합니다.

DROP FUNCTION의 세부 사항은 다음과 같습니다.

  • 문법

  • 특권

    • 대상 함수가 사용자가 소유한 스키마에 있거나, DROP ANY PROCEDURE 시스템 특권이 있어야 합니다.

  • 구성요소

구성요소
설명

schema

  • 제거할 함수가 속해있는 스키마의 이름을 명시

  • 생략하면 현재 사용자의 스키마로 인식

function_name

제거할 함수의 이름을 명시

  • 예제

다음은 DROP FUNCTION을 사용해 사용자 함수를 제거하는 예입니다.

hashtag
DROP INDEX

인덱스를 제거합니다. 제거된 인덱스를 이용하는 SQL 문장, 함수, 프러시저 등은 모두 무효화됩니다. 무효화 된 문장을 실행시키면 인덱스를 사용하지 않는 방법으로 최적화되거나 컴파일되어 다시 실행됩니다.

DROP INDEX의 세부 사항은 다음과 같습니다.

  • 문법

  • 특권

    • 다음 중 하나를 만족해야 DROP INDEX 문을 실행할 수 있습니다.

      • 인덱스가 자신의 스키마에 포함되어 있습니다.

      • DROP ANY INDEX 시스템 특권이 있습니다.

  • 구성요소

구성요소
설명

exist

IF EXISTS. 해당 옵션을 명시하면

  • 동일한 이름의 OBJECT가 존재하지 않는 경우에도 에러 로그를 발생시키지 않고 성공 메시지를 반환

  • OBJECT가 존재하는 경우에는 기존 DROP 문과 동일하게 동작

schema

  • 인덱스나 테이블의 스키마 이름

  • 생략하면 현재 사용자의 스키마로 인식됨

index_name

제거할 대상 인덱스의 이름

  • 예제

다음은 DROP INDEX를 사용해 인덱스를 제거하는 예입니다.

hashtag
DROP MATERIALIZED VIEW

실체화 뷰를 제거합니다.

DROP MATERIALIZED VIEW의 세부 사항은 다음과 같습니다.

  • 문법

  • 특권

    • 사용자가 소유한 스키마에 실체화 뷰를 제거하기 위해서는 별다른 특권이 필요하지 않다.

    • 다른 사용자가 소유한 스키마의 실체화 뷰를 제거하기 위해서는 DROP ANY MATERIALIZED VIEW 시스템 특권이 있어야 합니다. 그리고 실체화 뷰를 제거하기 위해서는 데이터베이스가 사용하는 테이 블, 뷰, 인덱스 등을 제거할 수 있는 권한이 필요합니다.

  • 구성요소

구성요소
설명

schema

  • 제거할 실체화 뷰가 속해 있는 스키마의 이름을 명시

  • 생략하면 현재 사 용자의 스키마로 인식

mview_name

제거할 실체화 뷰의 이름을 명시

PRESERVE TABLE

PRESERVE TABLE을 명시하면 실체화 뷰를 제거한 후에도 실체화 뷰의 내 용이 실체화 뷰와 동일한 이름의 테이블로 남게 됨

  • 예제

다음은 PRESERVE TABLE를 사용해 실체화 뷰를 제거하는 예입니다.

hashtag
DROP MATERIALIZED VIEW LOG

지정된 마스터 테이블에 실체화 뷰 로그를 삭제합니다.

DROP MATERIALIZED VIEW LOG의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

    • 테이블을 삭제하기 위한 특권이 있어야 합니다.

  • 구성요소

구성요소
설명

schema

  • 삭제할 실체화 뷰 로그의 마스터 테이블의 스키마를 명시

  • 생략하면 현재 사용자의 스키마로 인식

table

삭제할 실체화 뷰 로그의 마스터 테이블의 이름을 명시

  • 예제

다음은 DROP MATERIALIZED VIEW LOG를 사용해 실체화 뷰 로그를 삭제하는 예입니다.

hashtag
DROP OUTLINE

생성된 아웃라인을 제거합니다.

circle-info

참고

새로운 아웃라인을 생성하려면 “CREATE OUTLINE”을 참고합니다.

DROP OUTLINE의 세부 내용은 다음과 같습니다.

  • 문법

  • 구성요소

구성요소
설명

outline_name

제거할 아웃라인의 이름

  • 예제

다음은 DROP OUTLINE 을 사용해 역할을 제거하는 예입니다.

USE_STORED_OUTLINES 파라미터를 끄면 해당 쿼리의 아웃라인이 존재하더라도 적용하지 않습니다.

hashtag
DROP PACKAGE

데이터베이스에 저장된 패키지를 제거합니다.

DROP PACKAGE의 세부내용은 다음과 같습니다.

  • 문법

  • 특권

    • 제거할 패키지가 사용자의 스키마에 있거나, DROP ANY PROCEDURE 시스템 특권이 있어야 합니다.

  • 구성요소

구성요소
설명

BODY

  • BODY를 명시하면 패키지의 본문만 제거

  • 명시하지 않으면 패키지 명세와 본문이 함께 제거

  • 본문만 제거하면 이 패키지에 의존하는 객체를 무효화시키지는 않음

  • 그러나 본문을 다시 생성하기 전까지는 패키지의 프로시저나 함수를 호출할 수 없음

  • 패키지 전체가 제거되면 패키지 명세에 의존하고 있는 로컬 객체가 무효화됨

  • 이후 이 객체를 다시 참조하려고 하면 데이터베이스는 객체의 재컴파일을 시도

  • 패키지를 다시 생성하지 않은 상태라면 에러가 발생

schema

  • 제거할 패키지가 속해 있는 스키마의 이름을 명시

  • 생략하면 현재 사용자의 스키마로 인식

package_name

제거할 패키지의 이름을 명시

  • 예제

다음은 DROP PACKAGE를 사용하는 예입니다.

hashtag
DROP PROCEDURE

사용자 프러시저를 제거합니다. 제거된 사용자 프러시저를 포함하는 함수, 프러시저 등은 바로 무효화됩니다. 이렇게 무효화된 함수나 프러시저를 실행하려 하면 재컴파일을 시도하지만 이미 제거되었으므로 에러를 반환합니다.

DROP PROCEDURE의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

    • 대상 프러시저가 사용자 자신의 스키마에 있거나, DROP ANY PROCEDURE 시스템 특권이 있어야 한 다.

  • 구성요소

구성요소
설명

schema

  • 제거할 프러시저가 속해있는 스키마의 이름을 명시

  • 생략하면 현재 사용 자의 스키마로 인식

procedure_name

제거할 프러시저의 이름을 명시

  • 예제

다음은 DROP PROCEDURE를 사용하는 예입니다.

hashtag
DROP PROFILE

프로파일을 제거합니다.

circle-info

참고

프로파일을 생성하거나 변경하기 위해서는 “CREATE PROFILE”, “ALTER PROFILE”의 내용을 참고합니다.

DROP PROFILE의 세부 사항은 다음과 같습니다.

  • 문법

  • 특권

    • DROP PROFILE 시스템 특권이 필요합니다.

  • 구성요소

구성요소
설명

exist

IF EXISTS 해당 옵션을 명시하면

  • 동일한 이름의 OBJECT가 존재하지 않는 경우에도 에러 로그를 발생시키 지 않고 성공 메시지를 반환

  • OBJECT가 존재하는 경우에는 기존 DROP 문과 동일하게 동작

username

제거할 프로파일의 이름

CASCADE

  • 제거할 프로파일에 사용자가 속해 있는 경우 해당 사용자는 자동으로 DEFAULT 프로파일을 지정

  • 사용자가 속해 있는 프로파일을 CASCADE 절을 포함하지 않은 상태에서 제거하려고 하면, 에러를 반환하고 프로파일을 제거하지 않음

hashtag
DROP ROLE

생성된 역할을 제거합니다. 역할을 제거할 때에는 자동으로 해당 역할을 부여받은 모든 사용자와 다른 역할 에서부터 역할을 취소합니다. 현재 그 역할을 이용 중인 세션은 영향이 없으며, 이후에 생성되는 세션은 그 역할을 사용할 수 없습니다.

circle-info

참고

새로운 역할을 생성하거나 생성한 역할의 정보를 바꾸려면 “CREATE ROLE”, “ALTER ROLE”을 참고합니다.

DROP ROLE의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

    • DROP ROLE 시스템 특권이 필요합니다.

  • 구성요소

구성요소
설명

exist

IF EXISTS

해당 옵션을 명시하면

  • 동일한 이름의 OBJECT가 존재하지 않는 경우에도 에러 로그를 발생시키 지 않고 성공 메시지를 반환

  • OBJECT가 존재하는 경우에는 기존 DROP 문과 동일하게 동작

role_name

  • 제거할 역할의 이름

  • 해당 역할은 이미 CREATE ROLE을 통해 생성되어 있어야 함

  • 예제

다음은 DROP ROLE을 사용해 역할을 제거하는 예입니다.

위의 예를 보면, CREATE ROLE을 사용하여 역할을 생성하고, 생성된 역할을 u1이라는 사용자에게 허 가합니다. 그러고 나서 DROP ROLE로 역할을 제거하면 자동으로 사용자 u1에게 부여한 역할도 취소됩니다.

hashtag
DROP SEQUENCE

지정된 시퀀스의 정의를 제거합니다.

circle-info

참고

시퀀스를 생성, 변경하기 위해서는 “CREATE SEQUENCE”와 “ALTER SEQUENCE”의 내용을 참고합니다.

DROP SEQUENCE의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

    • 시퀀스가 자신의 스키마에 있거나, DROP_ANY_SEQUENCE 시스템 특권이 필요합니다.

  • 구성요소

구성요소
설명

exist

IF EXISTS 해당 옵션을 명시하면

  • 동일한 이름의 OBJECT가 존재하지 않는 경우에도 에러 로그를 발생시키 지 않고 성공 메시지를 반환

  • OBJECT가 존재하는 경우에는 기존 DROP 문과 동일하게 동작

schema

  • 제거할 시퀀스를 포함하는 스키마의 이름

  • 생략하면 현재 사용자의 스키마로 인식됨

sequence_name

제거할 시퀀스의 이름

  • 예제

다음은 CREATE_SEQUENCE의 예제에서 생성한 'test_seq'라는 시퀀스를 제거하는 예입니다.

hashtag
DROP SYNONYM

동의어를 제거합니다.

circle-info

참고

동의어를 생성하기 위해서는 “CREATE SYNONYM”의 내용을 참고합니다.

DROP SYNONYM의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

    • 사용자가 소유한 스키마에 속한 동의어이거나, DROP ANY SYNONYM 시스템 특권이 필요합니다.

    • 공유 동의어를 제거하기 위해서는 DROP PUBLIC SYNONYM 특권이 필요합니다.

  • 구성요소

구성요소
설명

PUBLIC

  • 공유 동의어를 제거하려면 PUBLIC를 명시해야 함

  • 이때는 동의어의 스키 마를 지정할 수 없음

schema

  • 제거할 동의어를 포함하는 스키마의 이름

  • 생략하면 현재 사용자의 스키 마로 인식

synonym_name

제거할 동의어의 이름

  • 예제

다음은 CREATE_SYNOMYM의 예제에서 생성한 emp와 pt라는 동의어를 제거하는 예입니다.

hashtag
DROP TABLE

테이블을 제거합니다. 테이블을 제거하면 테이블에 생성된 모든 제약 조건과 인덱스, 트리거 등 관련 객체도 제거되며, 파티션 테이블인 경우 모든 파티션이 제거됩니다.

테이블을 참조하고 있던 뷰, 함수, 프러시저, 패키지 등은 제거되지는 않으나 무효화 상태가 되므로 사용 할 수 없게 됩니다. 이후에 다시 같은 이름의 테이블이 생성되고, 제거된 객체를 사용할 수 있는 조건이 됩니다 면, 첫 번째 사용 후 다시 유효화 상태로 돌아온다.

DROP TABLE의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

사용자의 스키마에 있는 테이블을 제거하기 위해서는 별다른 특권이 필요하지 않다. 단, 다른 사용자의 스키마에 있는 테이블을 제거하기 위해서는 DROP ANY TABLE 시스템 특권이 있어야 합니다.

  • 구성요소

구성요소
설명

exist

IF EXISTS 해당 옵션을 명시하면

  • 동일한 이름의 OBJECT가 존재하지 않는 경우에도 에러 로그를 발생시키 지 않고 성공 메시지를 반환

  • OBJECT가 존재하는 경우에는 기존 DROP 문과 동일하게 동작

schema

  • 제거할 시퀀스를 포함하는 스키마의 이름

  • 생략하면 현재 사용자의 스키마로 인식됨

table_name

제거할 테이블의 이름

CASCADE CONSTRAINTS

제거할 테이블이 다른 테이블에 참조되는 FOREIGN KEY 제약조건이 설정된 상태라면 CASCADE CONSTRAINTS를 통해 FOREIGN KEY를 참조하는 테이블의 제약조건까지 연쇄적으로 제거되도록 설정해야만 테이블을 제거할 수 있음

PURGE

  • 초기화 파라미터 USE_RECYCLEBIN을 'Y'로 설정하여 RECYCLEBIN 기능을 사용하는 경우에는 PURGE 옵션을 지정하지 않으면 테이블을 제거해도 실제로 제거되지는 않고 이름만 바뀌게 됨

  • 반면에 초기화 파라미터 USE_RECYCLEBIN에 설정된 값이 'N'인 경우에는 PURGE 옵션과 상관없이 항상 테이블이 실제로 제거됨

  • 테이블을 실제로 제거하기 위해서는 PURGE 옵션을 지정해야 함

  • 제거된 이후에는 FLASHBACK TABLE 문장을 통해 테이블을 복구할 수 없음

  • FLASHBACK TABLE 문장에 대한 자세한 내용은 “FLASHBACK TABLE”을 참고

  • 예제

다음은 DROP TABLE을 사용해 테이블을 제거하는 예입니다.

hashtag
DROP TABLESPACE

테이블 스페이스를 제거합니다.

DROP TABLESPACE의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

    • SYSDBA 특권이 있어야 합니다.

  • 구성요소

구성요소
설명

identifier

제거할 테이블 스페이스의 이름을 명시

INCLUDING CONTENTS

  • 테이블 스페이스의 모든 객체를 동시에 제거

  • INCLUDING CONTENTS를 명시하지 않고, 객체를 저장하는 테이블 스페이스를 제거하려 하면, 에러를 반환하고 테이블 스페이스를 제거하지 않음

AND DATAFILES

테이블 스페이스 제거와 함께 구성하는 데이터 파일을 제거하려고 할 때 명시

CASCADE CONSTRAINTS

  • 제거할 테이블 스페이스에 저장된 테이블을 참조하는 모든 참조 무결성 제약조건도 함께 제거

  • 테이블 스페이스의 테이블을 참조하는 참조 무결성 제약조건이 정의되어 있는데, CASCADE CONSTRAINTS를 명시하지 않고 해당 테이블 스페이스를 제거하려고 하면, 에러를 반환하고 해당 테이블 스페이스를 제거하지 않음

  • 예제

다음은 테이블 스페이스를 제거할 때 INCLUDING CONTENTS를 포함시켜 테이블 스페이스와 해당 객 체와 데이터 파일까지 모두를 제거하는 예입니다.

hashtag
DROP TRIGGER

데이터베이스에서 트리거를 제거합니다. 만약 트리거가 설정된 테이블을 DROP TABLE 문으로 제거했다면, 트리거는 자동으로 제거됩니다. 즉 DROP TRIGGER 문을 실행하지 않아도 됩니다.

DROP TRIGGER의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

    • 사용자가 소유한 스키마에 있는 트리거이거나, DROP ANY TRIGGER 시스템 특권이 있어야 합니다.

  • 구성요소

구성요소
설명

exist

IF EXISTS 해당 옵션을 명시하면

  • 동일한 이름의 OBJECT가 존재하지 않는 경우에도 에러 로그를 발생시키 지 않고 성공 메시지를 반환

  • OBJECT가 존재하는 경우에는 기존 DROP 문과 동일하게 동작

schema

  • 제거할 트리거가 속해 있는 스키마를 명시

  • 생략하면 현재 사용자의 스키마로 인식

trigger_name

제거할 트리거의 이름을 명시

  • 예제

다음은 DROP TRIGGER를 사용해 트리거를 제거하는 예입니다.

hashtag

hashtag
DROP TYPE

사용자 정의 타입를 제거합니다. 제거된 사용자 정의 타입를 포함하는 함수, 프러시저, 패키지는 바로 무효 화됩니다. 이렇게 무효가 된 패키지 함수, 프러시저, 패키지를 실행하면 다시 컴파일을 시도하지만 이미 제 거되었으므로 에러를 반환합니다.

단, 제거할 사용자 정의 타입을 포함하는 사용자 정의 타입이 존재합니다면, FORCE 옵션을 주어야 사용자 정의 타입의 제거가 성공하며, 제거된 사용자 정의 타입을 포함하던 사용자 정의 타입은 바로 무효화됩니다. 무효화된 타입은 이를 사용하는 함수, 프러시저, 패키지의 실행될 때 또 는 이 사용자 정의 타입을 포함하는 다른 사용자 정의 타입이 컴파일될 때 컴파일을 시도합니다.

DROP TYPE의 세부 사항은 다음과 같습니다.

  • 문법

  • 특권

    • 대상 사용자 정의 타입이 사용자가 소유한 스키마에 있거나, DROP ANY TYPE 시스템 특권이 있어야 합니다.

  • 구성요소

구성요소
설명

schema

  • 제거할 사용자 정의 타입이 속해 있는 스키마의 이름을 명시

  • 생략하면 현재 사용자의 스키마로 인식

type_name

제거할 사용자 정의 타입의 이름을 명시

FORCE

제거할 사용자 정의 타입를 포함하는 사용자 정의 타입이 있는 경우에도 제 거를 강제

  • 예제

다음은 DROP TYPE을 사용해 사용자 타입를 제거하는 예입니다.

hashtag

hashtag
DROP TYPE BODY

바디를 가지는 사용자 정의 타입 즉 오브젝트 타입의 바디를 제거합니다. 바디를 제거해도 타입의 스펙이 무 효화되지 않습니다. 타입의 스펙이 무효화 되지 않으므로, 스펙을 의존하는 다른 스키마 오브젝트를 무효화 하지 않습니다.

DROP TYPE BODY의 세부 사항은 다음과 같습니다.

  • 문법

  • 특권

    • 대상 사용자 정의 타입이 사용자가 소유한 스키마에 있거나 DROP ANY TYPE 시스템 특권이 있어야 합니다.

  • 구성요소

구성요소
설명

schema

  • 바디를 제거할 사용자 정의 타입이 속해 있는 스키마의 이름을 명시

  • 생략하면 현재 사용자의 스키마로 인식

type_name

바디를 제거할 사용자 정의 타입의 이름을 명시

  • 예제

다음은 DROP TYPE BODY을 사용해 사용자 타입를 제거하는 예입니다.

hashtag
DROP USER

사용자를 제거합니다.

circle-info

참고

  1. 사용자를 생성하거나 변경하기 위해서는 “CREATE USER” , “ALTER USER”의 내용 을 참고합니다.

  2. SYS 사용자는 절대로 제거하면 안 됩니다.

DROP USER의 세부 사항은 다음과 같습니다.

  • 문법

  • 특권

    • DROP USER 시스템 특권이 필요합니다.

  • 구성요소

구성요소
설명

exist

IF EXISTS 해당 옵션을 명시하면

  • 동일한 이름의 OBJECT가 존재하지 않는 경우에도 에러 로그를 발생시키 지 않고 성공 메시지를 반환

  • OBJECT가 존재하는 경우에는 기존 DROP 문과 동일하게 동작

username

제거할 사용자의 이름

CASCADE

  • 제거할 사용자가 객체를 가진 경우 해당 객체와 함께 사용자를 제거

  • 객체를 가진 사용자를 CASCADE 절을 포함하지 않은 상태에서 제거하려고 하면, 에러를 반환하고 사용자를 제거하지 않음

  • 예제

다음은 DROP USER를 사용해 사용자를 제거하는 예입니다.

처음에 사용자를 생성했을 때는 해당 사용자가 아무런 객체를 만들지 않았으므로, DROP USER를 사 용하여 사용자를 제거할 수 있었다. 두 번째 사용자를 생성할 때는 해당 사용자로 접속하여 테이블을 생 성하였다. 해당 사용자는 t1이라는 테이블을 소유하고 있으므로, 단순한 DROP USER로는 제거할 수 없고, CASCADE 절을 덧붙여 사용했을 때만 제거할 수 있습니다.

hashtag
DROP VIEW

사용자가 소유한 스키마나 지정된 스키마에 속한 뷰를 제거합니다.

제거된 뷰를 참조하는 다른 뷰, 동의어 등은 제거되지 않고 무효화됩니다. 제거된 뷰를 대체하는 뷰를 생성 함으로써 그러한 객체를 다시 유효화할 수 있습니다.

circle-info

참고

뷰를 생성하기 위해서는 “CREATE VIEW”의 내용을 참고합니다.

DROP VIEW의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

    • 사용자가 소유한 스키마에 속한 뷰이거나 DROP ANY VIEW 시스템 특권이 필요합니다.

  • 구성요소

구성요소
설명

schema

  • 제거할 뷰를 포함하는 스키마의 이름

  • 생략하면 현재 사용자의 스키마로 인식됨

view_name

제거할 뷰의 이름

  • 예제

다음은 DROP VIEW를 사용해 뷰를 제거하는 예입니다.

다음은 DROP VIEW를 사용해 뷰를 제거하고, 그 뷰를 참조하던 객체를 다시 유효화하는 예입니다.

위의 예에서 뷰 v1을 제거하면 v1을 참조하던 v2를 더는 사용할 수 없습니다. 하지만, 뷰의 정의는 달라도 대 체할 수 있는 v1을 만들어 주면 다시 유효화하여 사용할 수 있습니다.

hashtag
EXPLAIN PLAN

특정 SQL 문장의 실행 계획을 지정된 테이블에 저장합니다. 디폴트로 PLAN_TABLE 테이블에 결과가 저장 되며, PLAN_TABLE 테이블과 같은 형태의 스키마를 갖는 테이블을 지정하면 해당 테이블에 결과를 삽입 할 수 있습니다. EXPLAIN PLAN 문은 DML에 가깝다. 그래서 SQL 문장을 실행하면 자동 커밋은 발생하지 않 는다.

EXPLAIN PLAN의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

    • 결과를 저장할 테이블에 대한 쓰기 권한이 필요합니다.

  • 구성요소

구성요소
설명

SET STATEMENT_ID

  • 결과를 저장할 테이블의 STATEMENT_ID 컬럼의 값을 지정

  • 결과 테이블의 다른 EXPLAIN PLAN 결과와 구별하기 위해 이 컬럼을 사용

  • 아무 것도 지정하지 않으면 NULL 값이 삽입됨

INTO table

  • 결과를 저장할 테이블의 이름을 지정

  • EXPLAIN PLAN 문을 실행하기 전 에 이미 존재하는 테이블이어야 함

  • 스키마를 생략하면 사용자 자신의 스키마로 자동 지정

FOR statement

실행 계획을 관찰할 SELECT, INSERT, UPDATE, DELETE 문장을 지정

  • 예제

다음은 EXPLAIN PLAN을 사용하여 실행 계획을 결과 테이블에 저장하는 예입니다.

hashtag
FLASHBACK TABLE

테이블을 특정 시점으로 돌리거나 제거한 테이블을 복원합니다. 특정 시점으로 테이블을 복원할 경우 복원 할 테이블의 이름을 원래 테이블의 이름과 다르게 하여 복구 후에도 기존 테이블이 남아 있도록 합니다. 따 라서 기존 테이블로 다른 시점의 FLASHBACK TABLE이 가능해진다.

FLASHBACK TABLE은 특정 시점의 데이터만을 복원해주며, 테이블과 관련된 인덱스, 트리거, 제약조건 은 복원되지 않습니다. 또한 초기화 파라미터 UNDO_RETENTION 시점까지 FLASHBACK TABLE이 가능 하지만 _TSN_TIME_MAP_SIZE의 크기가 UNDO_RETENTION보다 같거나 커야 합니다. 이는 $TB_SID.tip 파일에서 옵션으로 값을 설정할 수 있습니다.

FLASHBACK TABLE은 DDL이 수행된 이전의 시점으로는 불가능하며, 테이블 이외의 오브젝트에는 수행 되지 않습니다.

다음은 FLASHBACK TABLE이 불가능한 테이블입니다.

  • 시스템 테이블

  • 가상 테이블

  • AQ 테이블

  • 파티션 테이블

  • Cluster에 속해 있는 테이블

  • TEMP 테이블

  • External 테이블

  • DB Link를 통해 조회할 수 있는 테이블

만약 제거한 테이블을 복원할 경우에는 초기화 파라미터 USE_RECYCLEBIN을 Y로 설정하여 RECYCLEBIN 기능을 사용해야 합니다. 단, 다음과 같은 경우에는 USE_RECYCLEBIN을 Y로 설정하더라도 RECYCLEBIN 으로 오브젝트가 들어가지 않아 FLASHBACK TABLE이 불가능합니다.

  • TEMP 테이블을 DROP할 경우

  • SYS 계정의 오브젝트를 DROP할 경우

  • ALTER MOVE한 경우 원본 테이블

RECYCLEBIN 기능을 사용할 때 테이블을 제거하면 시스템이 테이블 및 인덱스, 트리거, 제약조건의 이 름을 생성하여 변경하기만 하고, 실제로는 제거하지 않습니다. 단, 제거할 테이블과 관련된 외래 키 제약조 건은 제거됩니다.

RECYCLEBIN 기능을 사용하면 테이블을 제거할 때 RECYCLEBIN 뷰에 포함된 테이블을 복원할 수 있습니다. 테이블을 복원하면 테이블의 이름은 이전 상태로 복구되거나 지정한 대로 변경되지만, 인덱스, 트리거, 제 약조건의 이름은 원래의 이름으로 복구되지 않습니다.

FLASHBACK TABLE의 세부 내용은 다음과 같습니다.

  • 문법

  • 구성요소

구성요소
설명

schema

  • 복원할 테이블을 포함하고 있는 스키마의 이름

  • 생략하면 현재 사용자의 스키마로 인식

table_name

  • 복원할 테이블의 이름

  • 테이블을 제거하기 전의 이름 또는 RECYCLEBIN 뷰를 참조하여 제거한 후 시스템이 변경한 이름으로 지정할 수 있음

  • 단, 같은 이름의 테이블이 RECYCLEBIN 뷰에 여러 개가 존재하는 경우 원래 이름을 지정하면 가장 최근의 이름으로 사용됨

TSN

특정 TSN으로 복원할 때 사용

TIMESTAMP

특정 TIMESTAMP로 복원할 때 사용

expression

  • TSN과 TIMESTAMP 구문으로 복원할 때 필요한 구문

  • TSN의 경우 특정 시점의 TSN이며, TIMESTAMP의 경우 특정 시간을 의미하는 구문

BEFORE DROP

  • 제거된 테이블을 복원

  • RENAME TO table_name 문을 사용하지 않을 때는 생략할 수 있음

RENAME TO table_name

  • 복원할 테이블의 이름을 원래 이름과 다르게 변경할 때 사용

  • 특히 이전에 사용하던 이름을 다른 테이블이 사용하고 있는 경우에 필요

  • 예제

다음은 FLASHBACK TABLE을 사용해 테이블을 복원하는 예입니다.

hashtag

hashtag
GRANT

시스템 특권과 역할, 스키마 객체 특권을 일반 사용자나 역할, 공유 사용자에게 부여합니다.

circle-info

참고

  1. 부여한 특권 또는 역할을 회수하기 위해서는 “REVOKE”의 내용을 참고합니다.

  2. 역할을 생성하거나 정보를 변경, 제거하기 위해서는 “CREATE ROLE”, “ALTER ROLE”, “DROP ROLE”의 내용을 참고합니다.

GRANT의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

    • GRANT를 이용하여 특권 또는 권한을 부여하는 데에는 해당 특권이나 권한에 따라 다른 특권이 필요합니다.

구성요소
설명

시스템 특권

  • 사용자 자신이 사용할 수 있게 부여받은 시스템 특권에 한해 가능

  • 단, 자 신이 사용할 수 있는 시스템 특권을 모두 부여할 수 있는 것은 아님

  • 사용자 자신이 사용 가능하게 부여받을 때 WITH ADMIN OPTION을 사용하 여 부여 받았어야 함

  • GRANT ANY PRIVILEGE 시스템 특권을 가지고 있는 경우라면 자신이 부여받지 않은 시스템 특권도 모두 부여할 수 있음

역할

  • 시스템 특권과 마찬가지로 WITH ADMIN OPTION을 사용하여 부여받은 역 할이거나 자신이 만든 역할이어야 부여가 가능

  • GRANT ANY ROLE 시스템 특권을 가지고 있는 경우라면 자신이 부여받지 않은 역할이라도 모두 부여할 수 있음

스키마 객체 특권

  • 스키마 객체 특권을 부여하는 것은 자신이 소유한 객체이거나 WITH GRANT OPTION을 사용하여 부여받은 스키마 객체 특권에 한해 가능

  • GRANT ANY OBJECT PRIVILEGE 시스템 특권을 부여 받았을 경우라면 자신이 부여받지 않은 스키마 객체 특권도 모두 부여할 수 있음

  • 구성요소

- grant

구성요소
설명

grant_sysprivs

시스템 특권이나 역할을 부여

grant_objprivs

스키마 객체 특권을 부여

- grant_sysprivs

구성요소
설명

system_privilege

  • 시스템 특권을 정의

  • 자세한 내용은 “시스템 특권”을 참고

role_name

  • 역할을 정의

  • 역할에 대해서는 “CREATE ROLE”, “ALTER ROLE”, “DROP ROLE”을 참고

ALL PRIVILEGES

  • 현재 사용가능한 모든 시스템 특권을 부여

  • GRANT ANY PRIVILEGE 시스템 특권을 가지고 있는 사용자만이 ALL PRIVILEGE 절을 사용할 수 있음

  • 부여할 수 있는 시스템 특권은 “시스템 특권”을 참고

TO grantee_clause

  • 특권이나 역할을 부여받을 대상이 됨

  • 대상은 일반 사용자, 역할, 공유 사용자 3종류

  • 공유 사용자에게 특권 또는 역할을 부여하면 모든 사용자에게 부여한 것과 동일한 효과를 갖게 되므로 주의해야 함

WITH ADMIN OPTION

  • 시스템 특권과 역할을 사용할 수 있는 사용 특권과 남에게 부여할 수 있는 관리 특권으로 나뉨

  • WITH ADMIN OPTION을 사용하면 두 특권(사용+관리)이 함께 부여됨

  • 이를 사용하지 않으면 부여받은 사용자는 특권을 사용할 수만 있고 다른 사용자에게 부여할 수는 없음

  • 반대로 GRANT ANY PRIVILEGE 시스템 특권을 부여받은 사용자의 경우 자신이 부여받지 않은 시스템 특권도 마음대로 부여할 수 있음

  • 역할의 경우엔 GRANT ANY ROLE 시스템 특권이 같은 역할을 하게 됨

  • 주의해야 할 점은 WITH ADMIN OPTION을 사용하여 해당 특권 또는 역할을 남에게 부여할 수 있는 관리 특권을 주었을 경우 사용 특권은 그대로 둔 상태 로 관리 특권만을 회수할 수 없음

  • 따라서 그 경우에는 부여한 시스템 특권 또는 역할 전체를 회수한 뒤 WITH ADMIN OPTION 없이 다시 그 시스템 특권 또는 역할을 할당해야 함

– object_objprivs

구성요소
설명

object_privilege_clause

스키마 객체 특권을 명시

(username.) object

  • 스키마 객체 특권의 대상이 되는 객체를 명시

  • username 부분이 생략되었을 경우 자신의 스키마 객체에서 해당 이름을 가진 객체를 찾게 됨

  • 만약 대상으로 동의어가 포함된 경우에는 해당 동의어의 기반 객체로 인식하고 처리하게즉 동의어에 스키마 객체 특권을 부여하거나 회수하는 것은 동의어의 기반 객체에 특권을 부여하거나 회수하는 것과 동일한 효과를 갖게 됨

TO grantee_clause

  • 스키마 객체 특권을 부여받을 대상이 됨

  • 대상이 될 수 있는 것은 일반 사용자나 역할, 공유 사용자 3종류

WITH GRANT OPTION

  • 시스템 특권의 WITH ADMIN OPTION과 마찬가지 역할을 함

  • 즉, 부여한 스키마 객체 특권을 다른 사용자에게 부여할 수 있는 특권까지 같이 부여하고자 할 때 사용됨

  • 하지만, 시스템 특권의 WITH ADMIN OPTION과는 커다란 차이가 있음

  • 자신의 스키마 객체가 아닌 다른 사용자의 스키마 객체를 WITH GRANT OPTION을 이용하여 스키마 객체 특권을 부여받은 사용자 A가, 또 다른 사용자 B에게 스키마 객체 특권을 부여한 경우 사용자 A의 스키마 객체 특권을 회수하면, 사용자 A가 부여한 사용자 B의 특권도 같이 회수됨

  • 또한, 시스템 특권에서의 역할과 마찬가지로, 자신의 스키마 객체에 대해서는 별도로 스키마 객체 특권을 부여받지 않아도, 모든 스키마 객체 특권과 해당 스키마 객체 특권을 다른 사용자에게 부여할 수 있는 특권까지 갖고 있음

  • GRANT ANY OBJECT PRIVILEGE 시스템 특권을 부여받은 사용자의 경우 자신이 부여받지 않은 객체에 스키마 객체 특권도 모두 부여할 수 있음

  • 이는 시스템 특권에서의 GRANT ANY PRIVILEGE와 동일한 역할을 합니다고 할 수 있음

  • 또한, 부여받는 객체가 일반 사용자나 공유 사용자가 아닌 역할일 경우에는 WITH GRANT OPTION은 사용할 수 없음

– object_privilege_clause

구성요소
설명

object_privilege

  • 스키마 객체 특권을 명시

  • 스키마 객체 특권의 종류는 아래의 “스키마 객체 특권”을 참고

colname

  • 스키마 객체 특권은 시스템 특권과는 달리 좀 더 세부적인 설정이 가능

  • 즉, 특정 객체 전체에 대한 특권이 아닌 객체의 일부 컬럼에 대해서만 제약적으로 특권을 부여할 수도 있음

  • 객체의 특정 컬럼에 대해서만 제약적으로 스키마 객체 특권을 부여하고자 할 경우에는 특정 컬럼을 나열하는 방식으로 지정할 수 있음

  • 하지만, 모든 스키마 객체 특권이 컬럼별 특권을 지정할 수 있는 것은 아님

  • 컬럼별 특권을 지정할 수 있는 스키마 객체 특권은 INSERT, REFERENCES, UPDATE뿐

ALL PRIVILEGES

  • 현재 사용가능한 모든 스키마 객체 특권을 부여

  • GRANT ANY PRIVILEGE 시스템 특권을 가지고 있는 사용자만이 ALL PRIVILEGE 절을 사용할 수 있음

– grantee_clause

구성요소
설명

user_name

스키마 객체 특권을 부여받을 일반 사용자를 명시

role_name

스키마 객체 특권을 부여받을 역할을 명시

PUBLIC

  • 스키마 객체 특권을 부여받을 공유 사용자를 명시

  • 공유 사용자에게 특권 또는 역할을 부여하면 모든 사용자에게 부여한 것과 동일한 효과를 갖게 되므로 주의해야

  • 예제

– grant_sysprivs

다음은 사용자를 생성하고, system_privilege에 특권을 명시해 그 사용자에게 CREATE SESSION

시스템 특권을 부여하는 예입니다.

처음 사용자를 생성하면, 첫 SELECT 문의 결과에서처럼 아무런 시스템 특권을 가지지 않은 상태가 됩니다. 이렇게 아무런 특권을 갖고 있지 않은 사용자가 데이터베이스에 접속해 어떤 작업을 하기 위해 서는, 기본적으로 CREATE SESSION 시스템 특권이 필요합니다. 위의 예에서는 생성된 사용자에게 CREATE SESSION 시스템 특권을 할당하고, 그 결과를 보여주고 있습니다.

다음은 생성된 사용자 U1에게 role_name에 역할을 명시해 RESOURCE 역할을 부여하는 예입니다.

RESOURCE 역할은 기본 역할로, 데이터베이스가 생성될 때 자동으로 생성됩니다.

다음은 자신의 스키마 객체를 생성하기 위한 기본적인 시스템 특권을 보여준다.

다음은 ALL PRIVILEGE를 사용하여 모든 시스템 특권을 부여하는 예입니다.

다음은 역할을 생성하고, 그 역할에 CREATE SESSION 시스템 특권을 부여하는 예입니다.

위의 예는 aaa라는 역할을 생성하고, 그 역할에 CREATE SESSION 시스템 특권을 부여하고 있습니다. 위의 예와 같이 역할에 특권을 부여하는 방법은 사용자에게 특권을 부여하는 방법과 동일합니다.

역할에 특권을 부여하는 것처럼 역할을 다른 역할에 부여할 수도 있습니다. 하지만, 다음과 같이 여러 역 할 서로가 서로를 부여받는 일은 허용하지 않습니다.

다음은 WITH ADMIN OPTION을 사용했을 때와 사용하지 않았을 때의 차이에 관한 예입니다.

위의 예에서는 사용자 u2, u3를 생성한 뒤 u2 사용자에게 CREATE SESSION 시스템 특권을 부여했 는데, 처음에는 특권만 부여하고, 그 다음에는 WITH ADMIN OPTION을 사용하여 부여하였다.

그런 뒤 사용자 u2로 접속을 해 보면, WITH ADMIN OPTION 을 이용하여 부여받은 CREATE TABLE 시스템 특권은 사용자 u3에게 부여할 수 있지만, 그렇지 않은 CREATE SESSION 시스템 특권은 부 여할 수 없습니다.

– grant_objprivs

다음은 object_privilege에 스키마 객체 특권을 명시해 사용자에게 스키마 객체 특권을 부여하는 예 입니다.

위의 예에서는 우선 사용자 u5, u6를 생성한 뒤 사용자 u5에게는 데이터베이스에 접속해서 스키마 객 체를 만들 수 있는 특권을, 사용자 u6에게는 데이터베이스에 접속할 수 있는 특권을 부여합니다.

사용자 u5로 접속하여 CREATE TABLE 문을 사용하여 테이블을 생성한 뒤 간단한 데이터를 삽입하 고, 해당 스키마 객체에 질의 특권을 사용자 u6에게 부여하여 사용자 u6이 u5의 테이블에 대한 질의 문을 실행할 수 있음을 볼 수 있습니다.

만약 사용자 u5가 사용자 u6에게 특권을 부여하지 않은 경우라면 다음과 같은 에러가 발생할 것입니다.

다음은 컬럼별로 특권을 지정하는 예입니다.

위의 예에서는 사용자 u5가 자신의 테이블 t1의 컬럼 A, B에 대해서 삽입과 갱신 특권을 사용자 u6에 게 부여한 것입니다. 사용자 u6은 사용자 u5의 테이블 t1중 컬럼 A와 B에 대해서만 삽입과 갱신을 할 수 있게 됩니다. 그 외의 컬럼 (위의 예에서는 C 컬럼) 에 대해 삽입 또는 갱신할 경우 TBR-8053: not enough privilege라는 에러가 발생하게 됩니다.

다음은 GRANT ALL을 사용하여 사용자 자신이 부여할 수 있는 모든 스키마 객체 특권을 부여하는 예입니다.

다음은 동의어에 특권을 할당하는 예입니다.

위의 예에서는 사용자 u5가 새로운 테이블 t3를 생성한 뒤 테이블 t3의 동의어 s3를 생성합니다. 그런 뒤 동의어 s3에 대해 질의 특권과 로우를 삽입하는 특권을 사용자 u6에게 부여합니다. 그러면 사용자 u6에게는 동의어가 가리키는 테이블 t3에 대한 특권이 부여되어, 직접 t3이라는 이름으로 질의 또는 로우를 삽입할 수 있게 됩니다.

– grantee_clause

다음은 공유 사용자에게 스키마 객체 특권을 부여하는 예입니다.

위의 예에서 보여주는 것과 같이 공유 사용자에게 스키마 객체 특권을 부여하는 경우 주로 CREATE SYNONYM 문을 사용하여 공유 동의어를 생성하고, 그 공유 동의어에 특권을 주고자 할 때입니다. 그 이외의 경우 함부로 사용하면 보안에 치명적인 문제가 생길 수 있습니다.

다음은 WITH GRANT OPTION을 사용하는 예입니다.

위의 예를 보면, WITH GRANT OPTION의 용도를 알 수 있습니다. 시스템 특권의 WITH ADMIN OPTION 과 마찬가지로 사용자 u5가 사용자 u6에게 WITH GRANT OPTION을 이용하여 부여한 질의 특권은 사용자 u6이 사용자 u7에게 다시 부여할 수 있습니다. 하지만, WITH GRANT OPTION 없이 부여받은 로 우 삽입 특권은 사용자 u6만 사용할 수 있고, 또 다른 사용자인 u7에게는 부여할 수 없습니다.

다음은 WITH ADMIN OPTION과 WITH GRANT OPTION의 차이점에 관한 예입니다.

WITH GRANT OPTION은 특권을 회수하면 특권을 받은 사용자가 부여한 또 다른 특권도 모두 같이 회수됩니다. 즉, 위의 예에서 사용자 u6에게 부여한 테이블 t4에 대한 스키마 객체 특권을 모두 회수하 면 사용자 u6이 사용자 u7에게 부여한 스키마 객체 특권도 같이 회수가 되어 사용자 u7도 더 이상 사 용자 u5의 테이블 t4에 대해 질의할 수 없게 됩니다.

hashtag
시스템 특권

다음은 시스템 특권을 정리한 표입니다.

구분
시스템 특권
설명

시스템

ALTER SYSTEM

ALTER SYSTEM 명령을 실행할 수 있음

SYSDBA

SHUTDOWN, ALTER DATABASE, CREATE DATABASE, ARCHIVELOG, RECOVERY 명령을 실행할 수 있음

세션

CREATE SESSION

  • 데이터베이스에 세션을 생성할 수 있음

  • 즉, 로그인할 수 있음

ALTER SESSION

ALTER SESSION 명령을 실행할 수 있음

테이블 스페이스

CREATE TABLESPACE

테이블 스페이스를 생성할 수 있음

ALTER TABLESPACE

테이블 스페이스를 변경할 수 있음

DROP TABLESPACE

테이블 스페이스를 제거할 수 있음

사용자

CREATE USER

사용자를 생성할 수 있음

ALTER USER

사용자 정보를 변경할 수 있음

DROP USER

사용자를 제거할 수 있음

테이블

CREATE TABLE

자신의 스키마에 테이블을 생성할 수 있음

CREATE ANY TABLE

임의의 스키마에 테이블을 생성할 수 있음

ALTER ANY TABLE

임의의 스키마에 있는 테이블을 변경할 수 있음

DROP ANY TABLE

임의의 스키마에 있는 테이블을 제거할 수 있음

COMMENT ANY TABLE

임의의 스키마에 있는 테이블에 주석을 추가할 수 있음

SELECT ANY TABLE

임의의 스키마에 속한 테이블, 동일어 테이블, 뷰, 실체화 뷰를 조회할 수 있음

INSERT ANY TABLE

임의의 스키마에 속한 테이블 또는 동일어 테이블에 로우를 삽입할 수 있음

UPDATE ANY TABLE

임의의 스키마에 속한 테이블 또는 동일어 테이블의 로우를 갱신할 수 있음

DELETE ANY TABLE

임의의 스키마에 있는 테이블의 로우를 제거할 수 있음

TRUNCATE ANY TABLE

  • 임의의 스키마에 있는 테이블에 TRUNCATE를 수행할 수 있음

  • 이 권한을 사용하기 위해서는 USE_TRUNCATE_PRIVILEGE 파라미터를 Y로 설정해야 함

인덱스

CREATE ANY INDEX

임의의 스키마에 속한 테이블 또는 실체화 뷰의 인덱스를 생성할 수 있음

ALTER ANY INDEX

임의의 스키마에 있는 테이블의 인덱스를 변경할 수 있음

DROP ANY INDEX

임의의 스키마에 있는 테이블의 인덱스를 제거할 수 있음

동의어

CREATE SYNONYM

자신의 스키마에 동의어를 생성할 수 있음

CREATE ANY SYNONYM

임의의 스키마에 동의어를 생성할 수 있음

DROP ANY SYNONYM

임의의 스키마에 있는 동의어를 제거할 수 있음

CREATE PUBLIC SYNONYM

공유 스키마에 공동 동의어를 생성할 수 있음

DROP PUBLIC SYNONYM

공유 스키마에 공동 동의어를 제거할 수 있음

뷰

CREATE VIEW

자신의 스키마에 뷰를 생성할 수 있음

CREATE ANY VIEW

임의의 스키마에 뷰를 생성할 수 있음

DROP ANY VIEW

임의의 스키마에 있는 뷰를 제거할 수 있음

실체화 뷰

CREATE MATERIALIZED VIEW

자신의 스키마에 있는 실체화 뷰를 생성할 수 있음

CREATE ANY MATERIALIZED VIEW

임의의 스키마에 있는 실체화 뷰를 생성할 수 있음

ALTER ANY MATERIALIZED VIEW

임의의 스키마에 있는 실체화 뷰를 변경할 수 있음

DROP ANY MATERIALIZED VIEW

임의의 스키마에 있는 실체화 뷰를 제거할 수 있음

시퀀스

CREATE SEQUENCE

자신의 스키마에 시퀀스를 생성할 수 있음

CREATE ANY SEQUENCE

임의의 스키마에 시퀀스를 생성할 수 있음

ALTER ANY SEQUENCE

임의의 스키마에 있는 시퀀스를 변경할 수 있음

DROP ANY SEQUENCE

임의의 스키마에 있는 시퀀스를 제거할 수 있음

SELECT ANY SEQUENCE

임의의 스키마에 속한 시퀀스에서 시퀀스 또는 동일어 시퀀스를 조회할 수 있음

역할

CREATE ROLE

역할을 생성할 수 있음

DROP ANY ROLE

역할을 제거할 수 있음

GRANT ANY ROLE

임의의 역할을 부여할 수 있음

ALTER ANY ROLE

역할을 변경할 수 있음

데이터베이스

ALTER DATABASE

데이터베이스를 변경할 수 있음

프러시저

CREATE PROCEDURE

자신의 스키마에 PSM을 생성할 수 있음

CREATE ANY PROCEDURE

임의의 스키마에 PSM을 생성할 수 있음

ALTER ANY PROCEDURE

임의의 스키마에 속한 PSM을 변경할 수 있음

DROP ANY PROCEDURE

임의의 스키마에 속한 PSM을 제거할 수 있음

EXECUTE ANY PROCEDURE

임의의 스키마에 속한 PSM을 실행할 수 있음

데이터베이스 링크

CREATE DATABASE LINK

자신의 스키마에 데이터베이스 링크를 생성할 수 있음

CREATE PUBLIC DATABASE LINK

공유 스키마에 데이터베이스 링크를 생성할 수 있음

DROP PUBLIC DATABASE LINK

공유 스키마에 데이터베이스 링크를 제거할 수 있음

디렉터리

CREATE ANY DIRECTORY

디렉터리 객체를 생성할 수 있음

DROP ANY DIRECTORY

디렉터리 객체를 제거할 수 있음

감시

AUDIT SYSTEM

시스템 감시의 사용이 가능

AUDIT ANY

디렉터리 또는 임의의 스키마에 있는 객체의 감시가 가능

라이브러리

CREATE LIBRARY

자신의 스키마에 라이브러리를 생성할 수 있음

CREATE ANY LIBRARY

임의의 스키마에 라이브러리를 생성할 수 있음

DROP ANY LIBRARY

임의의 스키마에 있는 라이브러리를 제거할 수 있음

EXECUTE ANY LIBRARY

임의의 스키마에 있는 라이브러리를 실행할 수 있음

특권

GRANT ANY OBJECT PRIVILEGE

모든 스키마 객체 특권을 부여할 수 있음

GRANT ANY PRIVILEGE

모든 특권을 다 부여할 수 있음

hashtag
스키마 객체 특권

다음은 스키마 객체 특권을 정리한 표입니다.

스키마 객체 특권
설명

SELECT

테이블, 뷰 또는 시퀀스에 질의문을 실행할 수 있음

INSERT

테이블 또는 뷰에 로우를 삽입할 수 있음

ALTER

테이블 또는 시퀀스의 정의를 변경할 수 있음

UPDATE

테이블 또는 뷰의 로우를 갱신할 수 있음

DELETE

테이블 또는 뷰로부터 로우를 삭제할 수 있음

TRUNCATE

  • 테이블에 TRUNCATE를 수행할 수 있음

  • 이 권한을 사용하기 위해서는 USE_TRUNCATE_PRIVILEGE 파라미터를 Y로 설정해야 함

INDEX

테이블에 인덱스를 생성할 수 있음

EXECUTE

함수 또는 프로시저를 컴파일하고 실행할 수 있음

REFERENCES

테이블 또는 뷰에 참조 무결성 제약조건을 정의할 수 있음

READ

디렉터리 객체에 읽기를 수행할 수 있음

WRITE

디렉터리 객체에 쓰기를 수행할 수 있음

스키마 객체 특권의 대상 객체

스키마 객체 특권을 정의할 수 있는 객체로는 테이블과 뷰, 시퀀스가 있습니다. 다음 표는 각 객체에 대해 어떤 스키마 객체 특권을 정의할 수 있는지를 나타낸 것입니다.

스키마 객체 특권
테이블
뷰
시퀀스
PSM 프로그램 (프러시저, 함수 등)
디렉터리

SELECT

O

O

O

INSERT

O

O

ALTER

O

O

UPDATE

O

O

DELETE

O

O

TRUNCATE

O

EXECUTE

O

INDEX

O

REFERENCES

O

O

READ

O

WRITE

O

hashtag
NOAUDIT

감사하고 있는 시스템 특권 또는 스키마 객체 특권의 감사를 해제합니다.

circle-info

참고

특권을 감사하기 위해서는 “AUDIT”의 내용을 참고합니다.

NOAUDIT의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

    • 시스템 특권의 감사를 해제하기 위해서는 AUDIT SYSTEM 시스템 특권을 부여받아야 합니다.

    • 다른 사용자가 소유한 스키마의 객체 또는 디렉터리 객체의 감사를 해제하기 위해서는 AUDIT ANY시스템 특권을 부여받아야 합니다.

  • 구성요소

- noaudit

구성요소
설명

audit_operation_clause

시스템 특권의 감사를 해제

audit_schema_object_clause

특정 객체에 대한 스키마 객체 특권의 감사를 해제

WHENEVER SUCCESSFUL

  • 명령의 성공, 실패에 따라 감사를 해제

  • 명령이 성공하였을 때 감사를 해제

  • 지정하지 않으면 성공, 실패 여부에 관계없이 감사를 해제

WHENEVER NOT SUCCESSFUL

  • 명령이 실패하였을 때 감사를 해제

  • 지정하지 않으면 성공, 실패 여부에 관계없이 감사를 해제

- audit_operation_clause

시스템 특권
설명

system_privilege

  • 감사를 해제할 시스템 특권을 지정

  • 시스템 특권의 종류는 “GRANT”의 "시스템 특권"을 참고

ALL PRIVILEGES

모든 시스템 특권의 감사를 해제

BY user_name

  • 감사를 해제할 사용자를 지정

  • 지정하지 않으면 모든 사용자에 적용됨

- audit_schema_object_clause

구성요소
설명

object_privilege

  • 감사를 해제할 스키마 객체 특권을 지정

  • 스키마 객체 특권의 종류는 “GRANT”의 "스키마 객체 특권"을 참고

ALL

  • 해당 객체에 사용할 수 있는 모든 스키마 객체 특권의 감사를 해제

  • 대상 객체의 종류에 따라 사용할 수 있는 스키마 객체 특권은 “ GRANT”의 "스키마 객체 특권의 대상 객체"를 참고합니다.

ON

스키마 객체 특권의 감사를 해제할 대상이 되는 객체를 지정

schema

  • 스키마 객체 특권의 감사를 해제할 객체가 속해 있는 스키마를 명시

  • 생략하면 현재 사용자의 스키마로 인식

object_name

디렉터리가 아닌 객체의 이름을 지정

DIRECTORY dir_name

디렉터리 객체의 이름을 지정

  • 예제

– noaudit

다음은 WHENEVER SUCCESSFUL을 명시해 명령이 성공했을 때 감사를 해제하도록 설정하는 예입니다.

– audit_operation_clause

다음은 BY user_name을 사용해 감사를 해제할 대상이 되는 사용자를 지정하는 예입니다.

– audit_schema_object_clause

다음은 ON을 사용해 감사를 해제할 대상이 되는 객체를 지정하는 예입니다.

hashtag

hashtag
PURGE

RECYCLEBIN 뷰에 포함된 스키마 객체를 완전히 제거합니다. 완전히 제거된 스키마 객체는 FLASHBACK TABLE 문으로 복원할 수 없습니다.

일반 purge의 경우 recyclebin에 있는 data를 drop segment queue로 이동시키므로, 일시적으로 tablespace의 사용량이 늘어난 것처럼 보일 수 있습니다.

RECYCLEBIN 뷰에 포함된 스키마 객체는 다음의 질의를 통해 확인할 수 있습니다.

PURGE의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

    • PURGE 대상이 되는 테이블, 인덱스를 제거하기 위한 특권이 있어야 합니다.

    • PURGE DBA_RECYCLEBIN 문을 실행하려면 SYSDBA 특권이 있어야 합니다.

  • 구성요소

구성요소
설명

TABLE table_name

  • 특정 테이블을 완전히 제거할 때 사용

  • 테이블을 제거하기 전의 이름 또는 RECYCLEBIN 뷰를 참조하여 제거한 후 시스템이 변경한 이름으로 지정할 수 있음

  • 단, 같은 이름의 테이블이 RECYCLEBIN 뷰에 여러 개가 존재하는 경우 원래 이름을 지정하면 가장 오래된 테이블이 제거됨

INDEX index_name

  • 특정 인덱스를 완전히 제거할 때 사용

  • 인덱스를 제거하기 전의 이름 또는 RECYCLEBIN 뷰를 참조하여 제거한 후 시스템이 변경한 이름으로 지정할 수 있음

  • 단, 같은 이름의 인덱스가 RECYCLEBIN 뷰에 여러 개가 존재하는 경우 원래 이름을 지정하면 가장 오래된 인덱스가 제거됨

RECYCLEBIN

USER_RECYCLEBIN 뷰에 포함된 모든 객체를 완전히 제거

DBA_RECYCLEBIN

DBA_RECYCLEBIN 뷰에 포함된 모든 객체를 완전히 제거

TABLESPACE tablespace_name

특정 테이블 스페이스에 존재하는 객체를 완전히 제거

USER user_name

USER 절을 지정하면 그 테이블 스페이스 안에서도 특정 사용자의 객체만 완전히 제거됨

  • 예제

다음은 PURGE을 사용해 테이블을 완전히 제거하는 예입니다.

hashtag

hashtag
RENAME

테이블, 뷰, 동의어 등의 이름을 변경합니다. 다른 스키마 객체의 이름은 변경할 수 없고 오직 사용자가 소유 한 스키마 객체의 이름만 변경할 수 있습니다. 이름을 변경한 스키마 객체와 관련된 제약조건과 인덱스, 특권 등은 이름이 변경됨과 동시에 함께 전환됩니다. 하지만, 이름을 변경한 객체를 참조하는 뷰, 함수, 프러시저 등은 바로 무효화 상태가 됩니다.

RENAME의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

    • 특별한 권한이 필요하지 않습니다.

  • 구성요소

구성요소
설명

old_name

변경할 스키마 객체의 원래 이름

new_name

변경할 스키마 객체의 새로운 이름

  • 예제

다음은 RENAME을 사용해 사용자의 이름을 변경하는 예입니다.

hashtag

hashtag
REVOKE

시스템 특권, 역할 또는 스키마 객체 특권을 일반 사용자, 역할 또는 공유 사용자에게서 회수합니다.

circle-info

참고

  1. 특권 또는 역할을 부여하기 위해서는 “GRANT”의 내용을 참고합니다.

  2. 역할을 생성, 변경, 제거하기 위해서는 “ CREATE ROLE”, “ALTER ROLE”, “DROP ROLE”의 내용을 참고합니다.

REVOKE의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

    • REVOKE를 이용하여 특권 또는 권한을 회수하는 데에는 회수할 특권 또는 권한별로 다른 특권이 필요 합니다.

회수 대상
설명

시스템 특권

  • 시스템 특권을 회수하기 위해서는, 해당 시스템 특권에 대해 자신이 사용할 수 있는 특권뿐만 아니라 관리할 수 있는 특권까지 부여를 받은 상태여야 함

  • GRANT ANY PRIVILEGE 시스템 특권을 가지고 있는 경우라면 자신이 부여받지 않은 시스템 특권도 모두 회수할 수 있음

  • 즉, GRANT를 사용하여 부여할 수 있는 것은 REVOKE를 이용하여 회수할 수도 있음

역할

  • 역할을 회수하기 위해서는 시스템 특권과 마찬가지로 WITH ADMIN OPTION을 통해 관리를 부여받은 역할이거나 자신이 만든 역할이어야 함

  • GRANT ANY ROLE 시스템 특권을 가지고 있는 경우라면, 자신이 부여받지 않은 역할이라도 모두 회수할 수 있음

  • 즉, GRANT를 사용하여 부여할 수 있는 것은 REVOKE를 이용하여 회수할 수도 있음

스키마 객체 특권

  • 시스템 특권이나 역할과는 조금 다름

  • 스키마 객체 특권은 자기 자신이 부여한 스키마 객체 특권만 회수할 수 있음

  • 자신의 스키마 객체에 대한 스키마 객체 특권이라도 자신이 부여한 스키마 객체 특권이 아니면 회수할 수 없음

  • GRANT ANY OBJECT PRIVILEGE 시스템 특권을 부여받았을 경우라면, 자신이 부여하지 않은 스키마 객체 특권도 회수할 수 있음

  • 단, 스키마 객 체 특권의 관리 특권을 가지지 않고, GRANT ANY OBJECT PRIVILEGE 시스템 특권을 사용하여 스키마 객체 특권을 부여한 경우에는, 해당 객체의 소유자가 해당 스키마 객체 특권을 회수할 수 있음

REVOKE를 이용하여 사용자의 특권을 회수하지 못하는 경우는 다음과 같습니다.

  • 사용자가 해당 특권 또는 역할을 부여받지 않은 경우

  • 사용자가 해당 특권 또는 역할을, 다른 역할을 통해 부여받은 경우

  • 구성요소

- revoke

구성요소
설명

revoke_sysprivs

시스템 특권이나 역할을 회수

grant_objprivs

사용자의 스키마 객체 특권을 회수

- revoke_sysprivs

구성요소
설명

system_privilege

  • 시스템 특권을 정의

  • 시스템 특권의 종류는 “GRANT”의 "시스템 특권"을 참고

role_name

  • 역할을 정의

  • 역할에 대해서는 “CREATE ROLE”, “ALTER ROLE”, “DROP ROLE”을 참고

ALL PRIVILEGES

  • 현재 사용가능한 모든 시스템 특권을 회수

  • 즉, 현재 사용가능한 모든 시스템 특권을 가진 사용자에게서 모든 시스템 특권을 회수하고자 할 때에만 사용할 수 있음

  • 일부 시스템 특권을 가진 사용자에게 ALL PRIVILEGES 절을 사용할 경우 에러가 발생

FROM grantee_clause

  • 특권이나 역할을 회수할 대상이 됨

  • 대상이 될 수 있는 것은 일반 사용자나 역할, 공유 사용자 세 종류

  • grant_objprivs

구성요소
설명

object_privilege

  • 스키마 객체 특권을 정의

  • 스키마 객체 특권의 종류는 “GRANT”의 "스키마 객체 특권"을 참고

  • GRANT와는 달리 객체의 컬럼별로 스키마 객체 특권을 부여한 것도 컬럼의 구분 없이 객체만 지정하여 회수할 수 있음

ALL (PRIVILEGES)

  • 해당 객체에 사용자 자신이 부여한 모든 스키마 객체 특권을 회수하고자 할 때 사용

  • PRIVILEGES 절은 생략 가능

  • 시스템 특권과는 달리 스키마 객체 특권에는 모든 특권을 가지고 있지 않아도 사용자가 자신이 부여한 스키마 객체 특권을 회수할 수 있음

  • USE_TRUNCATE_PRIVILEGE 파라미터가 꺼져 있어도 TRUNCATE 객체 특권을 회수

(username.) object

  • 스키마 객체 특권의 대상이 되는 객체를 나타냄

  • username 부분이 생략되었을 경우 해당 사용자 자신의 스키마 객체에서 해당 이름을 가진 객체를 찾게 됨

  • 만약 대상으로 동의어가 포함된 경우에는 해당 동의어의 기반 객체로 인식하고 처리하게 됨

  • 즉 동의어에 스키마 객체 특권을 부여하거나 회수하는 것은 동의어의 기반 객체에 특권을 부여하거나 회수하는 것과 동일한 효과를 갖게 됨

FROM grant_clause

  • 스키마 객체 특권을 회수할 대상이 됨

  • 대상이 될 수 있는 것은 일반 사용자나 역할, 공유 사용자 3종류

  • WITH ANY OBJECT PRIVILEGE 시스템 특권이 없으면, 사용자가 부여한 스키마 객체 특권에 한해 회수가 가능

CASCADE CONSTRAINTS

  • CASCADE CONSTRAINTS 절은 REFERENCES 스키마 객체 특권을 회수할 경우에만 의미가 있음

  • 즉, 이전에 REFERENCES 스키마 객체 특권을 허가한 상태에서 ALL (PRIVILEGES)로 허가한 모든 스키마 객체 특권을 회수할 경우에도 의미를 가지게 됨

  • CASCADE CONSTRAINTS 절을 사용하면 스키마 객체 특권을 회수할 대상에서 REFERENCES 스키마 객체 특권을 사용하여 생성한 참조 무결성 제약조건을 모두 지운 후 특권을 회수하게 됨

– grantee_clause

구성요소
설명

user_name

스키마 객체 특권을 회수할 일반 사용자를 명시

role_name

스키마 객체 특권을 회수할 역할을 명시

PUBLIC

스키마 객체 특권을 회수할 공유 사용자를 명시

  • 예제

– revoke_sysprivs

다음은 system_privilege를 명시해 사용자에게 CREATE SESSION 시스템 특권을 부여하고 회수하는 예입니다.

다음은 사용자 U1에게 부여한 기본 역할 CONNECT를 role_name에 명시하여 회수하는 예입니다.

다음은 ALL PRIVILEGES를 사용해 모든 시스템 특권을 부여하고 회수하는 예입니다.

ALL PRIVILEGES 절을 사용하여 시스템 특권을 회수할 경우 회수할 사용자 또는 역할이 모든 시스템 특권을 가지고 있어야만 원하는 작업이 정상적으로 실행됩니다. 위의 예에서 모든 시스템 특권을 가 지지 않은 사용자에게서 ALL PRIVILEGES 절을 사용하여 시스템 특권을 회수하려 할 때 TBR-7172: Unable to revoke a privilege granted by another user라는 에러 메시지가 나타나는 것도 볼 수 있습니다.

다음은 역할 r1을 생성한 후 기본 역할 CONNECT와 시스템 특권 CREATE SESSION을 부여하고, 회 수하는 예입니다.

– revoke_objprivs

다음은 사용자 u1이 테이블 t1을 생성하고, 테이블에 대한 스키마 객체 특권을 사용자 u2에게 부여한 후 회수하는 예입니다.

특권 부분에서 설명한 바와 같이 스키마 객체 특권을 부여할 때에는, 테이블 전체에 대한 특권과 테이 블의 일정 컬럼에 대한 특권을 구분해서 부여하였지만, 특권을 회수할 때에는 구분할 필요 없이 바로 회수가 가능합니다.

다음은 ALL PRIVILEGES를 통해 사용자 u1이 테이블 u1에 대해 사용자 u2에게 부여한 모든 스키마 객체 특권을 회수하는 예입니다.

시스템 특권과는 달리, 스키마 객체 특권은 자신이 부여한 특권만을 찾아서 회수해 주기 때문에, 대상 자가 해당 객체에 모든 스키마 객체 특권을 가지고 있지 않아도 동작합니다.

다음은 동의어를 사용하여 스키마 객체 특권을 회수하는 예입니다.

동의어를 사용할 경우 기반 객체에 특권을 부여 또는 회수하는 것과 동일한 효과를 갖게 되므로 위와 같이 동작하게 됩니다.

– grantee_clause

WITH ANY OBJECT PRIVILEGE 시스템 특권이 없으면, 사용자가 부여한 스키마 객체 특권에 한해 회수가 가능합니다.

다음은 그와 관련된 예입니다.

위의 예를 보면 사용자 u1이 사용자 u2에게 테이블 t1에 대한 질의 특권을 WITH GRANT OPTION을 사용하여 부여하였다.

즉, 사용자 u2는 사용자 u1의 테이블 t1에 대한 질의 특권을 관리할 수 있는 특권까지 갖게 되었습니다. 따 라서 사용자 u2가 사용자 u3에게 사용자 u1의 테이블 t1에 대한 질의 특권을 부여할 수 있습니다.

사용자 u1으로 돌아와 테이블 t1에 대한 스키마 객체 특권을 가진 사용자를 살펴보면 사용자 u2, u3이라는 것을 확인할 수 있습니다. 사용자 u3의 질의 특권을 회수하려 하면 자신이 부여한 스키마 객체 특권이 아니기 때문에 회수할 수 없습니다. 대신 사용자 u2에게 부여한 스키마 객체 특권을 회수하면, 사용 자 u2가 부여한 스키마 객체 특권까지 모두 회수가 되는 것을 볼 수 있습니다.

WITH GRANT OPTION 에 대한 자세한 내용은 “GRANT” 부분을 참고합니다.

다음은 CASCADE CONSTRAINTS를 사용해 참조 무결성 제약조건이 있는 스키마 객체의 특권을 회 수하는 예입니다.

사용자 u1이 테이블 t2에 대해 사용자 u2에게 참조 무결성 제약조건을 생성할 수 있는 스키마 객체 특 권을 부여하였고, 사용자 u2는 이를 이용하여 테이블 t3를 생성하였다.

사용자 u1이 사용자 u2에게 부여한 스키마 객체 특권을 회수하려 하면, 사용자 u2가 만든 참조 무결 성 제약조건 때문에 회수할 수 없게 됩니다. 하지만, CASCADE CONSTRAINTS을 사용하게 되면 사용 자 u2의 문제가 되는 참조 무결성 제약조건을 제거하고 스키마 객체 특권을 회수할 수 있습니다.

hashtag
TRUNCATE TABLE

테이블의 내용을 초기화합니다. 테이블의 모든 내용을 지우는 것은 DROP TABLE을 실행한 뒤 재생성하거 나 DELETE를 하는 것으로도 가능합니다.

TRUNCATE TABLE은 DELETE에 비해 몇 가지 장점이 있습니다.

– DROP TABLE 실행하고서 재생성하는 경우 인덱스, CONSTRAINT 등이 소멸되지만, TRUNCATE TABLE을 실행하면 모두 그대로 유지됩니다.

– DELETE보다 TRUNCATE TABLE이 훨씬 더 빠르게 수행됩니다.

TRUNCATE TABLE의 세부 내용은 다음과 같습니다.

  • 문법

  • 특권

    다음 중 하나를 만족해야 TRUNCATE TABLE 문을 실행할 수 있습니다.

    • 기반 테이블이 사용자 자신의 스키마에 포함되어 있습니다.

    • DROP ANY TABLE 시스템 특권이 있습니다.

    • TRUNCATE ANY TABLE 시스템 특권이 있습니다. 이 권한을 사용하려면 USE_TRUNCATE_PRIVILEGE 파라미터를 Y로 설정되어 있어야 합니다.

  • 구성요소

구성요소
설명

schema

테이블의 스키마의 이름입니다. 생략하면 현재 사용자의 스키마가 사용됨

DROP STORAGE

세그먼트의 익스텐트를 테이블 스페이스에 반환 (기본값)

  • 예제

다음은 TRUNCATE TABLE을 사용해 테이블의 내용을 초기화하는 예입니다.

Previous실체화 뷰Next데이터 조작어

Last updated