DB LINK 디비링크 란?
실 업무로 가보면 디비의 종류가 많이 있다.
제조사에 따라 아주 유명하고 멋지지만 가격 사악한 오라클, 짭라클? 티베로, mysql, 무료인데 막강한 mariadb, db2, 더티리드로 유명한 mssql 등등 더 많이 있지만, 유명한 걸 나열하자면 저렇고, 제품은 같은 거지만 물리적으로 분리를 시켜놓았을때, 예를 들어 개발용, 운영용, 테스트용 등으로 말이다. 혹은 사용자DB, 포털DB, 특정 공정마다 DB가 따로 있기도 한다.
이 들은 물리적으로 분리가 되어 있으니, 서로 데이터를 주고 받을 수가 없는데… 이를 가능하게 하는 것이 디비 링크 Database Link가 되겠다.
이번에는 DB링크가 어떻게 쓰였냐면, 운영에 디플로이를 했는데, 프로그램에 버그랑 개선사항이 발생했다. 하지만, 개발자에 소스들은 보통 개발DB에 물려 있어, 특정 데이터로 인한 버그를 수정하기에는 개발DB의 데이터으로 수정을 하긴 힘들다. 상상코딩을 해서, 운영에 배포한 후 확인하는건 참 거지같기 때문이다.(물론 상황이 여의치 않으면 저렇게라도 해야 한다.)
해서 해당 일부 데이터를 운영DB에서 개발DB로 옴기는 작업이 필요하다. 수많은 방법이 있겠지만, 가장 간단한건 DB링크이다.(그러나 보안상의 이유로 잘 제공하지 않거나 디비링크가 걸린 계정은 DBA아니면 오픈을 잘하지 않는다.)
디비링크는
SELECT * FROM 계정명.테이블명@디비링크명;처럼 물리적으로 분리되어 DB를 간단히, 마치 자기꺼인냥 조회를 가능하게 한다.
이제 MERGE INSERT나 SELECT INSERT 등의 쿼리로 간단히 데이터를 뽀려 올수 있게 된다.
링크를 지원하지 않는다면, 원본 데이터 DB에서 export 옵션등이나, insert쿼리를 뽑거나, txt, excel등으로 데이터를 추출한뒤 대상DB에서 추출한 데이터를 밀어 넣는 번거러운 작업을 해야 하니 말이다.
물론, 디비버 같은 툴에선 아주 간단히 insert쿼리를 만들어 주기도 한다.(하지만 많은 양을 옴기기엔 시간도 오래 걸리고 중간에 뻑날 수도 있다.) – 그래도 디비버 개짱임. ㅋ
디비링크명 확인하기
select * from dba_db_links;
select * from dba_db_links;
처럼 db_link 명을 확인 할수 있으니,
테이블 뒤에 @링크명 을 붙여 사용하면 된다.
디비링크 생성 및 삭제방법
create public database link testuser connect to testuser identified by 'password' using 'test2';당연하지만 생성권한이 있어야 한다. 앞서 말했듯이 보안상 문제로 잘 오픈하지 않으니 권한이 없을 확율이 58,000%다. ㅎ
그리고 db링크를 생성했으면, 그 링크를 사용할수 있는 권한들도 계정에 부여 해야 한다.
GRANT CREATE PUBLIC DATABASE LINT TO [사용자계정];drop public database link testuser;짭라클? 답게 오라클과 유사하다. 사실 @링크명은 대부분의 DBMS에서 쓰고 있다. 찔끔씩 다른점이 있으니, 직업 해보도록.~ ㅎ
아참 또 저걸 시노님을 주고 사용하면 줄여서 사용도 가능하다. ~!
DB링크 구성
여러방법
DB링크가 방향이 있는건 아니지만, 접속 계정에 따라 A에 DB링크가 없고, B에만 링크가 생성되어 있다면, B의 DB계정에 접속해서 A데이터를 가져오거나 자신의 데이터를 A로 옴기거나 해야 한다. A에서는 B에 접속을 못하니 말이다. 보통은 운영에서 개발로만 디비링크가 걸려 있는 경우가 많다.
서로의 계정에서 사용하려 하면, 각각 링크가 있어야 한다.
그 외에도 db가 아주 세분화 되어 있는 곳은 DB링크를 활용하여 구성하기도 한다. 구성을 할때, 서로의 계정에서(각 시스템에서 서로 데이터를 보거나 가져와야 하는 경우가 생긴다.) 실제로 어떤 회사에서 디비링크로 각 시스템을 구성했을때, 서로 디비링크를 가지고 있었다. 시스템이 몇개 되지 않는다면 문제가 되지 않겠지만, 3개, 4개, 혹은 앞으로도 계속 늘어나게 된다고 가정해보면 끔찍하다.
A, B, C, D의 시스템에서 각각 DB링크가, A에선, B링크, C링크, D링크가 필요하고, B시스템에선 A링크, C링크, D링크가 필요, 각각 자기 자신을 제외한 링크가 거미줄 처럼 필요하기 때문이다. (실제로 봤다. 첨엔 3개의 시스템만 구성되어 있어서 문제점을 인식하지 못한듯 하다. ㅎ) 이상태에서 E의 시스템이 새로 오픈된다면, 각각에서 링크들이 1개씩 더 생기고 E시스템에선 4개의 링크가 추가로 생성되어야 한다. 으으~~ ㅋ
각각의 시스템에서 진입점이 달라 생긴 문제다. 포털시스템의 개념으로 모든 시스템들은 진입점을 따로 가져가는 것이다. A, B, C, D 시스템에서 X라는 포털 진입점을 두는 것이다.
이러면 A, B, C, D 각각에서는 링크가 불필요 하고, X라는 진입점에만 각각의 링크가 있으면 되는 구조다. 표현이 아주 간단하기는 하지만, 이도 역시 완벽하지는 않다.
어떤 문제냐면 X, 즉 진입점이 서버 다운이 된다면, 나머지 살아 있는 모든 시스템에 접속을 못하는 그야 말로 X같은 상황이 발생하기에 때문이다.
무엇이 맞는지 정답은 없다. 투입된 회사마다 구성된 게 너무 다르니 말이다. 이것도 알고, 저것도 알아 둬서 잘 대응하도록. 위 개념들을 잘 숙지하도록 한다.
