(V8.1 REPLICATION) UPDATABLE SNAPSHOT환경 구축을 위한 초기 작업

Question

제품 : ORACLE SERVER
작성날짜 : 2001-07-19
(V8.1 REPLICATION) UPDATABLE SNAPSHOT환경 구축을 위한 초기 작업
=============================================================
1. 개요
=======
Symmetric Replication의 한 종류인 updatable snapshot환경의 구축을 위해서는
replication manager를 사용하도록 한다. 이 문서는 replication manager사용을
통해 snapshot group및 object 등을 등록하고 관리하기 이전에 master및 snapshot
site에서 미리 설정되고 수행되어야 하는 작업들을 정리한다.
이중 일부 작업은 replication manager를 통해서도 구현이 되지만, 정확한
수행이 요구되어 지는 작업에 대해서는 이 문서에서와 같이 직접 SQL command를
통해 수행되어지는 것이 권고된다.
Oracle 8.1.x부터는 snapshot과 materialized view가 동의로 사용되어지나, 이
문서에는 snapshot으로 표시한다.
2. Init.ora parameters
======================
아래와 같은 initialisation parameter들이 추가되거나 수정되어져야 한다.
아래의 설정은 master site와 snapshot site모두 설정이 필요하며, master site가
하나뿐인 경우는 job_queue부분과 parallel_ parameter의 경우는 설장할 필요가
없다.
Parameter 이름 권장되는 초기 값
COMPATIBLE 8.1.5.0.0 이상
SHARED_POOL_SIZE 20M ~ 40M 정도가 추가로 요구
PROCESSES 현재 값에서 12정도 추가
GLOBAL_NAMES 반드시 TRUE
OPEN_LINKS 4, 추가되는 master site당 2 증가
DISTRIBUTED_TRANSACTIONS 최소 5 이상 (기본값은 trsactions/4)
가되는 master site당 2 증가
REPLICATION_DEPENDENCY_TRACKING TRUE
아래의 값은 상황에 맞게 조정하여 사용한다.
JOB_QUEUE_INTERVAL 10 초
JOB_QUEUE_PROCESSES 3, 추가되는 master site당 1씩 증가
PARALLEL_MAX_SERVERS 10
PARALLEL_MIN_SERVERS 2, max server의 갯수와 동일한것이 권장
parallel propagation을 사용하지 않고자
하면 설정하지 않는다.
SNAPSHOT_ 로 시작하는 parameter나 JOB_QUEUE_KEEP_CONNECTIONS parameter는
Oracle 8.1에서는 없어졌으므로 지정하지 않도록 한다.
3. Tablespace 요구 사항
=======================
다음은 replication을 사용하기 위해 추가적으로 필요한 tablespace용량이다.
Tablespace 권장사항
SYSTEM 최소 40 Mb free space
ROLLBACK SEGMENTS 최소 30 Mb free space
TEMPORARY 최소 20 Mb free space
4. Replication Catalogue 설치
==============================
database생성시에 replication catalog를 설치하지 않았다면, Database
Configuration Assistant 를 이용하여 Advance Replication Option부분을
database에 추가하도록 하거나, 아니면 다음과 같이 작업한다.
cd $ORACLE_HOME/rdbms/admin
sqlplus internal
SQL>spool rep.log
SQL>@catrep
SQL>spool off
이 script는 약 1시간 정도 수행되며, spool을 받아 수행에 문제가 있었는지
이후에 확인하도록 한다.
[주의] 이 script를 수행하게 되면, replication관련 table과 queue등이 system
owner로 생성되게 된다.
그러므로 이후에 replication작업이 일시 중단되어 queue가 커지게 되면,
system user의 default tablespace에 부담이 되므로 system owner의
default tablespace를 tools나 그외 replication관리를 위한 별도의
table로 일시 지정하도록 한다.
SQL>ALTER USER sysem DEFAULT TABLESPACE REPTBS;
catrep의 수행이 끝나면 spool로 생긴 rep.log도 확인하여 보고, 아래 문장을
통해 invalid상태인 object를 확인하고 재 compile을 시도한다.
SQL> SELECT OWNER, OBJECT_NAME FROM ALL_OBJECTS
WHERE STATUS = 'INVALID';
이때 만약 SYS나 SYSTEM package의 body가 invalid로 나타나면 다음과 같이 재
compile을 시도한다. package body만 invalid인데 aler package문장에서 compile
body대신 compile이라고만 하면 그 package에 대한 definition이 변경되어,
이 package와 dependency관계에 있는 다른 object도 invalid상태가 되도록 한다.
작업이 성공적으로 끝났으면, system user의 default tablespace의 원래대로,
tool나 system으로 수정한다.
SQL> alter user system default tablespace system;
5. Setup NET8
=============
Replication환경에 포함된 모든 server는 listener를 구동하도록 하며, snapshot
site에서는 master site를 가리키는 service alias를 tnsnames.ora file에 등록하
도록 한다.
또한, replication manager를 사용하는 client도 tnsnames.ora file에 master와
snapshot site와 연결가능하도록 service alias를 net8 easy configuration등을
통하여 등록하도록 한다.
6. Replication Manager Setup Wizard
===================================
위의 작업이 모두 끝났으면 앞으로의 작업은 replication manager를 통해서도
수행 가능하다.
그러나 이 문서에 포함된 내용은 replication환경 설정시 한번만 필요한 작업이며,
이 부분에 대한 사소한 실수도 이후 사용에 문제를 야기하기 때문에, 여기에 포함된
작업만큼은 sql command를 통해 직접 작업하기를 권고한다.
Replication manager가 포함되어 있는 OEM version은 1.4부터이며, Oracle8.1의
경우는 2.1이 최적화되어 있다. 그러나 그 이전 version도 사용가능하다.
7. Replication Users
=====================
일반적으로, multi-master환경보다는 updatable snapshot환경이 더 보안이 문제시
된다. multi-master의 경우는 일반적으로 중앙에서 같은 db admin에 의해 관리
되는것이 일반적이나 snapshot의 경우는 지역적으로 떨어져 별개로 관리되는 경우가
많아 그 snapshot에서 master site의 database에 손상을 주는 일을 막는것이
중요하여, user구성은 multi-master환경보다 복잡하다.
Snapshot Site Master Site
Replication administrator
Snapshot replication administrator ---> Proxy snapshot administrator
Propagator ---> Receiver
Refresher ---> Proxy refresher
Snapshot Owner(s) ---> Proxy refresher
- Replication administrator: master site에서, master group들의 구성과
관리를 책임진다.
- Snapshot administrators: snapshot site에서 snapshot replication group을
구성하고 관리하는 책임을 지며, master site의 Proxy administrator가
master group의 최소한의 access만 허용하게 된다.
- Propagators: deferred transaction을 master site에 전달하면, master site의
Receiver가 전달받은 data를 master table에 적용시킨다.
- Refreshers: snapshot site에서 master site의 변경된 data를 snapshot
site로 끌어오는 역할을 하며, master site의 Proxy refresher는 master
site의 table에 대한 최소한의 acess만을 허용한다.
이러한 user들의 생성하고 이용하는 방법은 여러가지로 가능하다. 아래에서는,
그중 가장 일반적으로 사용되는 방법을 기술한다.
8. Replication user 생성 및 권한 부여
=====================================
Oracle 8.1부터 updatable snapshot 환경 구축시 trusted와 untrusted두가지
방법이 가능하다. untrusted의 경우 snapshot site가 master site와 같은 관리자
아래에 포함되지 않아 보안을 더 강화해야 하는 model이다.
하나의 master site에 snapshot group이 여러개이고, 각 snapshot별로, 이
snapshot group을 공유하는것이 아니고, 별개로 사용하는 경우 서로 다른
snapshot이 사용하는 group에 대해 보안을 유지하려면 untrusted model을 사용해야
하나 실제 이러한 환경으로 구성되는 일은 거의 없고, 작업의 번거로움으로 이
문서에는 trusted model에 대해서는 설명한다.
8.1 Master Site user와 권한
(1) Replication Administrator (REPADMIN)
SQL>CONNECT system/<password>
SQL>CREATE USER repadmin IDENTIFIED BY <password>
DEFAULT TABLESPACE <tablespace name>
TEMPORARY TABLESPACE <tablespace name>;
SQL>GRANT connect, resource TO repadmin;
SQL>EXECUTE dbms_repcat_admin.grant_admin_any_schema('repadmin');
SQL>GRANT comment any table TO repadmin;
SQL>GRANT lock any table TO repadmin;
만약 replication group이 어느 특정 schema에만 한정된다면,
grant_admin_any_schema대신 grant_admin_schema를 사용하여도 된다.
(2) Proxy snapshot administrator / Receiver / Proxy refresher (SNAPPROXY)
master site의 proxy snapshot administrator, receiver, proxy refresher는
하나의 user로 관리하는 것이 일반적이다. 이러한 SNAPPROXY user를 생성하지
않고 REPADMIN user가 이러한 역할도 수행하도록 설정할 수 있으나, 그렇게
되면 snapshot site에 너무 많은 권한을 부여하게 되어 바람직하지 않다.
replication manager를 이용해 이러한 user를 생성하면 master site에 연결된
snapshot site마다 각각의 snapproxy_n과 같은 형태로 user를 생성하나,
같은 snapshot group에 대하여 이렇게 각각의 user를 생성하는 것은 의미가
없으므로 권장되지 않는다.
SQL>CONNECT system/<password>
SQL>CREATE USER snapproxy IDENTIFIED BY <password>
DEFAULT TABLESPACE <tablespace name>
TEMPORARY TABLESPACE <tablespace name>;
(3) Proxy snapshot administrator privileges
SQL>CONNECT system/<password>
SQL>BEGIN
dbms_repcat_admin.register_user_repgroup(
username => 'snapproxy',
privilege_type => 'proxy_snapadmin',
list_of_gnames => NULL);
SQL>END;
SQL>/
register_user_repgroup procedure를 통해 권한을 부여한다. 이때, "create
session" 과 dbmsobjgwrapper / dbms_repcat_untrusted package에 대한
"execute"권한이 부여된다.
Replication group에 table을 add하게 되면 그 table에 대한 "select" 권한이
부여된, master objects에 대한 DML권한은 이 user에게 부여되지 않는다.
(4) Receiver privileges
SQL>CONNECT system/<password>
SQL>BEGIN
dbms_repcat_admin.register_user_repgroup(
username => 'snapproxy',
privilege_type => 'receiver',
list_of_gnames => NULL);
SQL>END;
SQL>/
이 문장을 통해 "create session" 과 dbms_defer_internal packages,
dbms_defer package에 대한 "execute"권한이 부여된다. 그러나 이것도
마찬가지로 master object에 대한 DML권한을 부여하지 않는다.
또한 receiver는 replication object를 추가한 후 replication support시에
생성되는 <schema>.<object name>$RP (LOB table에 대해서는 $RL)에 대한
execute권한을 부여 받아 master site에 변경사항을 적용하게 된다.
(5) Proxy refresher privileges
SQL>CONNECT system/<password>
SQL>GRANT create session TO snapproxy;
SQL>GRANT select any table TO snapproxy;
(6) Schema Owner(s) (여기에서는 REPUSER로 명시)
SQL>CONNECT system/<password>
SQL>CREATE USER repuser IDENTIFIED BY <password>
DEFAULT TABLESPACE <tablespace name>
TEMPORARY TABLESPACE <tablespace name>;
SQL>GRANT connect, resource TO repuser;
8.2 Snapshot Site user와 권한
(1) Snapshot administrator / Propagator / Refresher (SNAPADMIN)
snapshot administrator, propagator, refresher에 대해서 하나의 user로
관리하는것이 일반적이다.
SQL>CONNECT system/<password>
SQL>CREATE USER snapadmin IDENTIFIED BY <password>;
DEFAULT TABLESPACE <tablespace name>
TEMPORARY TABLESPACE <tablespace name>;
(2) Snapshot administrator 권한
SQL>CONNECT system/<password>
SQL>EXECUTE dbms_repcat_admin.grant_admin_any_schema('snapadmin');
SQL>GRANT comment any table TO snapadmin;
SQL>GRANT lock any table TO snapadmin;
(3) Propagator 권한
SQL>EXECUTE DBMS_DEFER_SYS.REGISTER_PROPAGATOR('snapadmin');
(4) Refresher 권한
SQL>GRANT create any snapshot TO snapadmin;
SQL>GRANT alter any snapshot TO snapadmin;
refresher와 대응하는 master site의 proxy refrsher에 의해 master site의
table에 대한 "select any table" 권한을 가지게 된다.
(5) Schema Owner(s) (여기에서는 REPUSER로 명시)
replicate되고자 하는 table에 대한 master site의 schema와 동일한 이름의
shema가 snapshot site에서도 필요하다. 단 password는 같을 필요는 없다.
만약 다른 schema에 대해서 updatable snapshot을 생성하면, snapshot생성시는
오류없이 만들어지지만, create_snapshot_repobject 수행시에 아래와 같이
오류가 발생할 것이다.
ORA-23306: schema <schema name> does not exist
ORA-23308: object <schema name>.<object name> does not exist or is invalid
아래 문장과 같은 schema owner생성시 주의할 점은 이 권한을 role을 통해
부여하지 말고 직접 주어야 한다는것이다. 즉, 이미 connect, resource등을
통해 create table과 같은 권한은 부여된 상황임에도 불구하고, 이후에
procedure나 package등에서 이 권한이 필요한 경우 role을 통해 부여된 것은
인식이 되지 않고 ORA-1031이 발생하기 때문에 아래와 같이 직접 권한을
부여하여야 한다.
SQL>CONNECT system/<password>
SQL>CREATE USER repuser IDENTIFIED BY <password>
DEFAULT TABLESPACE <tablespace name>
TEMPORARY TABLESPACE <tablespace name>;
SQL>GRANT connect, resource TO repuser;
SQL>GRANT create table TO repuser;
SQL>GRANT create snapshot TO repuser;
이 user가 master site에 대해서 수행할 수 있는 권한에 대해서는 이 user에서
master site로 생성하는 database link를 어느 user로 connect하느냐에 달려
있으며 이것은 9.4에서 설명한다.
(6) End Users
snapshot schema에 있는 snapshot을 이용하는 user가 별도로 존재할 수
있으며, 이 경우 특별한 권한이 추가적으로 필요하지는 않고, snapshot
object에 대한 필요한 권한을 부여하면 된다.
9. Database Link
================
database link를 생성하기 전에 중요한 것은 replication 환경에 포함된 모든
database는 고유한 global name을 가지고 있어야 한다. default global name은
<db_name>과 동일하나 다음과 같이 문장을 통해 global name을 수정가능하다.
그러므로 db_name이 같더라도 이렇게 global name을 수정하여 replication
환경을 구성할 수 있다.
SQL>ALTER DATABASE RENAME GLOBAL_NAME TO <new global name>;
SQL>SELECT * FROM GLOBAL_NAME;
updatable snapshot환경에서 database link가 제대로 구성되지 않으면 이후
작업에 계속 문제가 생기므로 주의하여야 한다. 이 database link는 snapshot
site에서 master site로만 구성하면 되며, 반대로 master site에서 snapshot
site로 구성할 필요는 없다.
(1) Public Database Links
Net8 connection alias를 이용하여 다음과 같이 public database link를
만든다. 이후 생성되는 private link는 using절을 포함하지 않게 되며,
모두 public database link와 동일한 이름의 db link이름을 가져야 한다.
(global_names=true이기 때문)
SQL>CONNECT system/<password>
SQL>CREATE PUBLIC DATABASE LINK <remote databases global name.world>
USING 'Net8 alias';
여기에서 표현한 Net8 alias는 snapshot site의 tnsnames.ora file에 정의
되어 있어야만 한다.
(2) Snapshot Administrator / Snapshot propagator / refresher
snapshot administrator와 proxy snapshot administrator 다음과 같이 private
database link가 필요하다.
SQL>CONNECT snapadmin/<password>
SQL>CREATE DATABASE LINK <remote databases global name.world>
CONNECT TO snapproxy IDENTIFIED BY <password>;
(3) Schema Owner (여기에서는 REPUSER로 명시한다)
snapshot을 가지고 있는 모든 schema는 master site에 private database
link를 생성해야 한다. 이때, "Schema to Schema" 와 "Schema to Proxy
Refresher" 두가지를 고려할 수 있다.
만약 link를 schema to schema방식으로 생성하게 되면, snapshot owner는
쉽게 master site로 연결하여, master table에 DDL이나 DML을 수행가능하다.
이것은 일반적으로 바람직하지 않으므로 master의 proxy refresher로
private database link를 만들도록 권고된다. master에서 proxy refresher와
proxy administrator가 동일한것이 일반적으로 결국 proxy administrtor에게
연결하면 된다.
이렇게 되면 snapshot의 schema owner는 proxy refresher user에 의해,
master table에 대한 "select any table"권한은 가지게 되지만, DDL이나,
DML은 허용되지 않으므로 더 안정적이다.
SQL>CONNECT repuser/<password>
SQL>CREATE DATABASE LINK <remote databases global name.world>
CONNECT TO snapproxy IDENTIFIED BY <password>;
(5) End User
database link가 필요하지 않다.
9.6 Testing Database Links
database link생성 작업이 끝나면 다음과 같이 하여, 각 user별로 database
link 생성이 올바로 되었는지 확인하도록 한다.
SQL>CONNECT user/<password>
SQL>SELECT * FROM DUAL@<database link name>
10. schedule설정
================
1 ~ 9번까지 성공적으로 수행되었다면 이제 replication manager를 이용하여,
replication/snapshot group과 object를 추가할 수 있다.
replication manager를 이용시 master site는 repadmin user로 접속하고,
snapshot site는 snapadmin user로 접속하도록 한다.
snapshot site의 변경 작업을 master site로 주기적으로 push시키고, 이렇게
push된 data를 또 다른 주기로 purge시키는 scheduling이 필요하다.
이것은 replication manager를 이용하려면, 아래 menu를 이용하면 된다.
- Scheduling --> Scheduled Links
- Database Information --> Purge Job Tab
이 작업을 sql문으로 수행하려면 다음과 같은 문장을 snapshot site에서
수행한다.
SQL>CONNECT snapadmin/<password>
SQL>BEGIN
dbms_defer_sys.schedule_push(
destination => '<destination databases global name>.WORLD',
interval => '/*10:Mins*/ sysdate + 10/(60*24)',
next_date => sysdate,
stop_on_error => FALSE,
delay_seconds => 0,
parallelism => 1);
SQL>END;
SQL>/
SQL>BEGIN
dbms_defer_sys.schedule_purge(
next_date => sysdate,
interval => '/*1:Hr*/ sysdate + 1/24',
delay_seconds => 0,
rollback_segment => '');
SQL>END;
SQL>/

Answer 1