|
Oracle System Documentation
원본출처 : http://bora.dacom.co.kr/~mhan/oracle/article/oradocu.html
이글은 상당히 오래된 글로서 이전에 저가 처음 DBMS 공부시에 이리 저리 찾아 다니다가 접했던 글입니다. 당시 Dictionary table 에 대해서 제대로 이해를 못하고 있다가 이글을 읽고서 도움이 되었던 기억이 나서 올려 둡니다. 참고하시기 바랍니다.
=============================
여러분이 운영하고 있는 오라클 시스템을 잘 정리하여 문서화한 관리를 하고 있는지 살펴보라. 여러가지 이유가 있겠지만 대부분 문서화 되지 않은 오라클 시스템을 선임자로 부터 물려 받아 또, 그렇게 관리하고 있는 경우가 많을것이다. 여러분이 책임지고 있는 데이타베이스를 재생성하여야 할 상황에 직면하였을때 EXPORT와 IMPORT가 가능한 환경이라면 재생성 작업은 손쉽게 처리해버릴 수 있겠지만 그렇지 않은 경우 DBA는 이 작업을 위한 DDL을 새로 만들어야 할 경우가 있었을 것이다.
DBA는 현재 시스템의 procedure, view, constraint등 database 요소들을 파악하기 쉬우면서도 가능하면 갱신이 필요하지 않는 형태로 문서화하여 정리하기를 원할것이다. DBA는 오라클이 제공하는 Data Dictionary를 이용하여 database 구조를 문서화하는 SQL을 만들 수 있고 필요한 DDL을 재생성할 수도 있다. 이것을 수행하는것은 전적으로 DBA 책임이라 할것이다.
Data Dictionary
오라클의 data dictionary는 table과 view로 구성되어 있다. 가장 아랫단계의 구조물은 X$로 시작하는 테이블들이다. X$ table은 DBA가 select는 할 수 있지만 내용을 이해하기는 힘들고, 이에 대한 자료를 구하기도 어렵다. X$를 파악하는데 무수한 밤을 지새우느니 이 부분은 오라클 몫으로 남겨두는것이 나을 것이다.
Data dictionary의 다음 층은 $ table들이다. COL$나 TAB$같이 이것은 X$ table보다는 DBA가 읽어 이해하기가 용이하다. 그러나 이 부분도 DBA가 꼭 필요한 경우가 아니면 건드리지 않는것이 생산적일것이다.
Data dictionary의 세번째 층은 V$로 시작되는 view들이다. 일반적으로 대부분의 script들이 이 V$ view를 이용하고 있다.
Dictionary의 마지막 층은 DBA_로 시작하는 view들이다. 이 view들은 V$와 $로 시작하는 view와 table들로부터 만들어져, oracle data dictionary를 가장 손쉽게 파악할 수 있도록 제공된다. USER_나 ALL_ view들은 DBA_ view를 기본으로 하여 생성된 것이다.
Data Dictionary를 access하는 유용한 script들은 오라클 시스템을 파악하여 정리하는데 훌륭한 수단이 될것이다. 시스템 문서화는 크게 DDL 같은 '구조'에 대한 문서와 그 구조에 담겨진 '내용'에 대한 문서로 나누어 볼수 있다.
Database
데이타베이스에는 다음과 같은 것들이 포함되어 있다.
구조물
Tablespace와 해당 Datafile들
Control Files
Redo Logs
Rollback Segments
Tables
Indexes
Database 초기화 파일
Clusters
내용물
View 정의 내용
Constraints
Procedures
Functions
Packages
Package Bodies
Triggers
User definitions
Roles
Grants
Database Links
Snapshots와 Snapshot Logs
이 글에서는 이들을 재생성하기 위한 DDL을 만들거나 이들을 문서로 정리하기 위하여 필요한 SQL및 PL/SQL을 어떻게 만드는지에 대하여 언급할 것이다.
제일 먼저 Control File에 대하여 문서화하여야 한다. 왜냐면 MAXDATAFILES, MAXLOGFILES, MAXMEMBERS등 oracle instance에 대한 특수 정보를 control file이 가지고 있기 때문이다.
Control file을 재생성하는 script를 준비하여 두는것은 아주 좋은 생각일것 같다. 오라클이 default로 어떻게 생성되는지 잘 모르는 사람이 oracle instance를 만들었을 경우에는 대개 비효율적인 오라클 시스템일 경우가 많다. DBA가 자신의 오라클이 MAXDATAFILES=20 이나 32로 설정되어 있고 이것이 너무 작게 설정되었다는것을 발견할수 있을 것이다. 이 경우 DBA는 control file을 재생성 하기 위한 script를 만들어서 MAXDATAFILES값을 변경하면 데이타베이스 자체를 재구축 안하고도 쉽게 시스템을 변경할 수 있다. 또 disk crash가 발생하여 control file이 깨졌을 경우를 생각할 수 있다. Oracle이 startup된다고 해도 database는 사용할 수 없는 상태가 된다. Control file rebuild script를 가지고 있다면 이 상황도 손쉽게 처리할 수 있다.
DBA는 항상 아래 명령어로 control file을 backup해 둘수 있다.
ALTER DATABASE BACKUP CONTROLFILE to 'filename' REUSE;
그렇지만 이 명령어를 수행하여 backup한 file은 오라클만이 읽을 수 있다.
오라클 구조가 변경되었을 경우에 control file을 항상 backup하는것이 바람직하다.
Control file 내용에 대한 기록을 가진 table은 없다. v$parameter 에는 control file 위치 정보만 있을 뿐이다. 따라서 DBA는 다음 명령어로 control file을 문서화하여야 한다.
ALTER DATABASE BACKUP CONTROLFILE TO TRACE NORESTLOGS;
이 명령어는 .TRC file을 떨어뜨린다.
Database 초기화 파일 문서화
초기화 파일은 INIT.ORA 또는 initSID.ora로 생성하는데 이 또한 아주 중요한 정보이다. 그러나 이 initSID.ora 파일에는 모든 파라메터가 기술되어있지 않다. 모든 파라메터의 값을 보려면 V$PARAMETER 테이블을 검색하여야 한다. 아주 간단한 SQL*Plus script로 이 값들을 문서화 할수 있고 또 손쉽게 완벽한 초기화 파일을 다시 만들수 있을 것이다.
Database 자체의 문서화
Control file과 초기화 파일이 정리되었으면 다음에는 데이타베이스 자체를 정리하여야 한다. 데이타베이스를 생성한 CREATE DATABASE 명령어를 재생해내는 스크립트가 필요할것이다. 이 명령어를 재생해내려면 3개의 시스템 테이블이 필요할것이다.
DBA_DATA_FILES : SYSTEM tablespace datafile의 위치
V$LOGFILE : Redo log file의 위치와 크기
V$LOG : Redo log의 구조
복수의 datafile과 redo log, redo log group등을 처리하기 위하여 커서와 temporary table을 이용한 복잡한 스크립트가 만들어졌다. 이 복잡한 스크립트가 다음과 같은 간단한 내용을 출력하는것이 좀 허망하기도 하다.
CREATE DATABASE TIGER1
CONTROLFILE REUSE
LOGFILE (
THREAD 1 GROUP 1 (
'/vol12/oracle1/TIGER1/log1TIGER1.dbf'
)
THREAD 1 GROUP 2 (
'/vol12/oracle2/TIGER1/log2TIGER1.dbf'
)
THREAD 1 GROUP 3 (
'/vol12/oracle3/TIGER1/log3TIGER1.dbf'
)
)
DATAFILE '/vol12/oracle1/TIGER1/systTIGER1.dbf' SIZE 41943040 REUSE
NOARCHIVELOG
;
Tablespace 문서화
DBA_TABLESPACES와 DBA_DATA_FILES를 이용하여 tablespace정보를 문서화하는 스크립트를 만들수 있다. Tablespace는 복수의 datafile로 구성되기떄문에 이 정보의 추출을 위해서는 PL/SQL이 필요할것이다.
Rollback Segment 문서화
데이타베이스에 다른 object 이 생성되기 전에 rollback segment가 반드시 생성되어야 한다. DBA_ROLLBACK_SEGS와 V$_ROLLSTAT 뷰를 이용하여 rollback segment를 똑같이 재생성할 수 있는 DDL을 만들기 위한 스크립트를 만들수 있다.
Role, Grant, User의 문서화
데이타베이스에 table, index, constraint 등의 object을 생성하기 전에 적절한 role과 object을 소유하기 위한 user가 준비되어야 할것이다. 이와 관계된 정보는 여러 테이블에 흩어져 있지만 다행이도 동일한 구조를 가진 테이블이어서 간단한 query문으로 정보를 얻어낼수 있다. 다음 테이블들에서 정보를 얻을 수 있다.: DBA_TS_QUOTAS, DBA_USERS, DBA_COL_PRIVS, DBA_ROLE_PRIVS, DBA_ROLES, DBA_TAB_PRIVS, DBA_SYS_PRIVS
Table 문서화
어느덧 데이타와 작접 관계가 없는 부문은 문서화가 완료되었다. 이제 응용시스템 테이블을 문서화 하기로 한다.
이 테이블들은 DBA_TABLES와 DBA_TAB_COLUMNS 뷰에서 정보를 얻을수 있다. PL/SQL을 이용하여 recursive 관계를 가지는 table과 table column정보를 문서화할 수 있을것이다..
이 단계에서는 table constraint는 제외하는것으로 하자. 이유는 Constarint가 유효하지 않은 상태에서 데이타를 탑재하도록 하기 위해서 이다. 나중에 별도의 스크립트로 primary key, foreign key, null, default등의 constraint를 생성하는 script를 만들기로 한다.
Database Constraint 문서화
대부분 constraint 들은 CREATE TABLE을 하면서 생성시키는데, 반면에 constraint 이름을 부여하는 경우가 드문것이 보통이다. 생성자가 constraint 이름을 부여하지 않으면 오라클은 'SYS_C00123' 같이 'SYS_C'에 일렬번호를 부여하여 constraint 이름을 부여한다. DBA는 PL/SQL을 이용하여 constraint를 re-build하거나 re-name할 수 있다. 테이블이나 일렬번호같이 테이블당 복수개의 constraint가 생성되는 경우, Primary key는 PK, Unique는 UK, Foreign key는 FK, check는 CK식으로 오라클은 테이블에 간단한 suffix를 붙이는 방식으로 constraint이름과 그 관련된 인덱스를 만든다. 예를 들어 'FK_ACTCNTL_1'은 테이블 'ACTCNTL'의 첫번째 FOREIGN KEY를 의미한다.
테이블 constraint 정보는 DBA_INDEXES, DBA_CONS_COLUMNS, DBA_CONSTRAINTS 뷰에서 찾을 수 있다.
Index 문서화
인덱스를 생성하는 이유는 보통 4가지가 있다. Primary key 를 지원, Unique값 지원, Foreign key 지원 또는 성능 향상을 위한 목적이다. 인덱스 정보는 DBA_IND_COLUMNS와 DBA_INDEXES 뷰에서 얻을 수 있다.
Sequence 문서화
Sequence가 표준 SQL의 부분이 아니기 때문에 문제가 발생할때까지 많은 사람들이 이를 간과하는 경향이 있다. Sequence의 최대값 또는 최소값을 초과하거나, 하나의 sequence에 과중한 부하가 걸릴 경우에 sequence 장애가 발생할 수 있다. Sequence를 문서화함으로써 sequence가 어떻게 생성되었는지 아니면 필요할때 sequence를 재생성할 수 있는 script를 보유할 수 있다. Import나 SQL*Loader를 하는 경우 key로 사용되는 sequence가 범위를 초과하여 reset을 하여야 할 경우가 발생할 수 있다. 미리 sequence에 대한 정리를 문서화하여 가지고 있었다면 이런 경우에 신속히 대응할 수 있을 것이다. Sequence를 재생성 하기위한 SQL*Plus 나 PL/SQL script는 DBA_SEQUENCES의 정보를 이용하여 만들수 있다.
이제 문서화할 나머지들은 데이타베이스 '구조'에 대한것이 아니라 거기 담겨진 '내용'들에 대한 것이 된다. Package, package body, procedure, function, trigger, view등이 이에 해당된다.
Package, Package Body, Procedure, Function의 문서화
Oracle 7에서는 PL/SQL 구조를 저장된 객체로 데이타베이스내에 탑재할수 있다. 가장 낮은 수준의 객체는 procedure와 function이다. Procedure와 function은 애플리케이션 또는 pakage네의 function으로 그룹화될수 있다. Package, Package body, procedure, function같은 PL/SQL의 저장 객체를 생성하는 모든 DDL은 DBA_SOURCE 뷰 내에 저장되고 그에 대한 추가 정보가 DBA_OBJECTS 뷰에 저장된다. 이 두개의 테이블을 join하는 script로써 위에 언급한 어떤 객체라도 재생성할 수 있다.
Trigger 문서화
참조 무결성을 지원, 스냅샷 로직을 지원, 계산되는 테이블 값을 갱신하는데 등등 다양한 데이타베이스 기능을 구현하기 위하여 트리거를 이용한다. 참조 무결성이나 스냅샷을 위한 트리거는 오라클 커널이 자동으로 생성하여 준다. 이들 이외의 모든 트리거에는 unique한 이름을 부여하여 DBA가 검색하여 관리할 수 있게 하는것이 좋다.
이미 오라클이 자동으로 생성한 트리거를 파손하지 않기 위해서는 CREATE OR REPLACE 문보다는 CREATE문을 사용하는것을 권고하고 싶다. 트리거에 대한 정보는 DBA_TRIGGERS와 DBA_TRIGGER_COLS 뷰에서 얻을 수 있다.
View 문서화
미리 join을 해둔다거나 보안을 위하여 또는 복잡한 데이타를 쉽게 검색하게 하기 위하여 뷰를 사용하곤 한다. 개발자는 뷰를 생성하지만 그것을 문서화하는것을 지나쳐버리는 경우가 흔하다. 뷰를 문서화하기 위한 정보는 DBA_VIEWS 뷰에서 찾을 수 있다. 이 결과를 읽을 수 있게 하기 위해서는 long 값과 session linesize 변수를 조정할 필요가 있을것이다. 최대 길이를 알기 위하여는 DBA_VIEWS의 text_length column을 쿼리해볼 수 있다. "select max(text_length) from dba_views'
Snap Shot과 Snap Shot Log 문서화
DBA_SNAPSHOTS 와 DBA_SNAPSHOT_LOGS 뷰를 이용하여 snapshot과 snapshot log 문서화를 할 수 있다. PL/SQL 로 snapshot과 snapshot log를 재구축하는 script를 만들수 있다. 그러나 이 부분은 오라클 release마다 새롲게 바뀌기 때문에 고정된 문서화 방법을 마련하는것이 곤란한점이 있다.
Database Link문서화
SYS.LINK$ 테이블이나 DBA_DB_LINKS 뷰의 정보를 이용하여 database link를 재생성하는 script를 만들수 있다. 보안을 위하여 DBA_DB_LINKS에는 암호 정보가 없다. 따라서 SYS.LINK$를 사용하는것이 바람직하다.
|
