드디어 PostgreSQL 9.2.2가 나왔습니다.
큰 문제들은 이제 다 정리된듯 합니다.

http://www.postgresql.org/about/news/1430/

iPhone 에서 작성된 글입니다.
 SQL Deveroper는 Oracle corp.에서 배포하는 Oracle 개발, 관리 등을 지원하는 개발 Tool입니다. Oracle Homepage에서 무료로 받아서 사용할 수 있으며, 현재 안정 버전은 3.0이며 "3.1 Early Adopter" 버전도 받아서 사용할 수 있습니다. 이 글을 작성하던 시점에는 3.0이 최신빌드였는데, 3.1이 정식으로 나왔습니다. (아래의 푸른 글 상자 안의 내용을 추가했습니다. 최신 버전에 대한 정보는 아래의 글 상자 내용을 참조하세요.)

Oracle SQL Developer 3.1 (3.1.07.42)

 February 7, 2012

출처 : http://www.oracle.com/technetwork/developer-tools/sql-developer/downloads/index.html

To install Oracle SQL Developer 3.1 download the file, there is no in-place upgrade available, you must unzip the file into an empty folder. Select the "Use folder names" checkbox when unzipping the file. You can migrate your settings from Oracle SQL Developer 1.5.x or SQL Developer 2.1.x.. See the Release Notes 3.1 for more details.

JDK Support
Oracle SQL Developer 3.0 is shipped with JDK1.6.0_11. However, you can connect to and use any JDK 1.6.0_11 or above. To use an existing JDK, download the zip files listed below "with JDK already installed."

Use Check for Updates to install:
  • Third-party database drivers for Sybase, SQL Server and MySQL. For more information on setting up the third-party drivers, see Migrations: Getting Started
  • Version control systems, Concurrent Versions System (CVS), Serena Dimensions or Perforce.

Check for Updates also supports an increasing number of Third-Party extensions. These are available with separate licensing agreements and are developed, tested and maintained by third-party vendors.



뒷북이 되어버린... 3.1 Early Adopter 버전입니다.

 
 3.1 버전을 설치했더니, 기본적으로 Oracle과 MS Access에 접근할 수 있게 되어있네요. 추가 설정 작업을 해주면 Microsoft SQL Server, Sybase, IBM DB2에도 접근할 수 있습니다. (Update 메뉴를 통해서 확장 기능을 검색해보면 MySQL, SQL Server 접속 기능도 설치할 수 있는데, 3.1 버전은 아직 정식 버전이 아니라서 그런지 설치를 할 수 없네요.)

 실행하면 화면에 위와 같은 창이 뜨고, 진행막대가 지나갈 겁니다. Java로 되어 있어서 그런지 (Oracle JDeveloper 기반인것 같다. VisualVM(정확한 이름인지는 모르겠다.)으로 상태를 모니터링하면서 보니까 이름이 JDeveloper로 뜨네요.) 초기 기동이 아주 느립니다. 토드와 맞짱 뜰만한 기동 시간이라니... 아 토드 보단 쪼금 빨랐던거 같습니다. 아마도...
  

0. Oracle Database
 Oracle database는 기본적으로 접속이 가능하다. TNS와 IP기반의 접속이 모두 가능하며 쓸만합니다.
 

1. MySQL 접속이 가능하도록 설정하기
1-1. MySQL JDBC Driver 다운로드 받아서 설치하기
  mysql.com의 다운로드 메뉴에서 Connector라는 항목을 선택하면 Connector/J라는 항목이 있다. 여기에서 다운로드 받을 수 있다. 다운로드 받은 파일의 압축을 풀어서 jar file을 원하는 위치에 저장하면 된다.

1-2. SQL Developer에 MySQL JDBC Driver 설정하기
환경설정 메뉴의 "데이터베이스 > 타사 JDBC 드라이버"를 클릭하면 설정 화면이 나옵니다.

1-3. SQL Developer 접속 설정하기
아래 이미지를 보시면 짐작이 가시겠죠? IP 혹은 Hostname, 그리고 계정 정보 등이 필요합니다.


 

2. Microsoft SQL Server에 접속이 가능하도록 설정하기
2-1. SQL Server JTDS Driver 다운로드 받아서 설치하기
  SQL Server는 MS에서 제공하는 JDBC Driver를 사용하면 SQL Developer가 인식하지 못한다. 대신에 Open source로 만들어지는 JTDS Driver를 이용하면 된다. Sourceforge에서 JTDS로 검색하면 찾을 수 있으며, 아래의 "관련 자료 다운로드"의 링크를 따라가면 바로 찾을 수 있다. 다운로드 받은 파일의 압축을 풀어서 jar file을 원하는 위치에 저장하면 된다.
 
2-2. SQL Developer에 JTDS Driver 설정하기
환경설정 메뉴의 "데이터베이스 > 타사 JDBC 드라이버"를 클릭하면 설정 화면이 나옵니다.


2-3. SQL Developer 접속 설정하기
아래의 이미지를 보시면 MySQL과 다른점이 있다면 "Windows 인증 사용"일겁니다. 그외에는 뭐...IP 혹은 Hostname, 계정 정보 등이 필요합니다.




<참고문서>

2. Oracle SQL Developer 3.1 Release Notes


<관련 자료 다운로드>



 MySQL Storage Engine들을 비교해볼 일이 생겨서 자료를 찾아봤습니다. 5.1 버전과 5.5 버전의 영문 메뉴얼을 보면서 정리한 내용입니다. MySQLKorea의 5.1버전 한글 번역판도 참고 했습니다.


1. MyISAM
Transaction을 지원하지 않지만 기본 Storage engine이며 많이 사용되고 있다. Table을 각각 독립적인 File에 저장한다. 5.5. 버전을 기준으로 256 TB까지 저장할 수 있다. Transaction을 지원하지 않는 대신 빠르고, 디스크 공간을 덜 차지하며, Update를 위한 메모리 공간도 적게 사용한다.
Transaction을 지원하지 않는 MyISAM 때문에 MySQL은 RDBMS로 인정해주지 못하겠다는 의견도 있었습니다. ("그러면 엑셀도 DB냐??"같은 의견이었죠.) 이제는 InnoDB같이 Transaction을 지원하는 Engine도 기본으로 설치되고 (설치는 되지만 여전히 사용 여부는 운영자의 판단이죠.), Transaction 지원을 포기한 대신에 빠른 속도와 가벼운 시스템 부하 등도 하나의 컨셉으로 받아들여지는것 같습니다. 하지만... Transaction을 지원하지 않는것은 큰 약점이라고 생각합니다. DB에서 처리해줄 Transaction을 Application상에서 구현해줘야 하니까요.


2. Memory
Table을 Memory에 저장하는 engine이다. 서버 재기동시 모든 data가 삭제된다. 5.5 버전 기준으로 RAM의 여유공간만큼 저장할 수 있다. Hash index를 지원한다.
Memory상에 Table이 직접 올라가 있으니 조회 속도는 엄청 좋을거라 생각합니다. 물론 시스템 부하가 얼마나 걸리는지, 과연 비싼 서버 메모리 비용을 부담할 만큼의 이점이 있는지는 실제 테스트를 한뒤 결정해야한다고 생각합니다.


3. Merge
여러개의 Table을 하나의 Table처럼 사용할 수 있게 해주는 Storage engine이라고 한다.
이부분은 음... 어떻게 보면 재밌게 쓸 수 있을거 같은데, 다음에 좀더 알아보고 정리하겠습니다.


4. InnoDB
Transaction을 지원하는 Storage engine이다.(기본 설정은 Auto commit이다) Foregine key 제약 사항, Clustered index, Row level lock을 지원하며 최대 64 TB까지 저장할 수 있다. Oracle과 유사하게 Tablespace에 data를 저장한다. 기본으로 설치용 바이너리 배포판에 포함되어 있다.
 SUN Microsystems가 Oracle에 인수되기 이전에 이미 Oracle사에 인수되어서 한때 MySQL 진영에서 InnoDB를 대체할 Storage Engine을 개발하려는 움직임이 있었죠.


5. BDB
BDB는 BerkeleyDB의 약자이다. InnoDB와 마찬가지로 Tarnsaction을 지원하는 storage engine이다. 다른 점이 있다면 Table을 저장할 때 MyISAM처럼 Table별로 독립된 File을 생성해서 저장한다는 점이다. 5.5 버전의 문서에 지원하는 Storage engine에서 제외된 걸로 봐서 앞으로의 공식 지원은 불투명한 상태이다. (뭐 이건 주관적인 생각입니다.)
 BerkeleyDB 역시 InnoDB와 마찬가지로 Sun Microsystems 인수 이전에 Oracle에 인수되었죠.(맞을겁니다.) MySQL과 별도로 단독으로 Application에 내장되어서 파일 기반의 DB로도 사용 가능합니다. 활용도가 높다고 생각합니다. 앞으로 어떻게 될지는 지켜봐야 겠네요.


6. Archive
대용량의 데이타를 인덱스 없이 저장하기 위한 Storage engine이다. INSERT, SELECT는 지원하지만, DELETE, UPDATE는 지원하지 않는다. 저장할 수 있는 크기에 제한이 없다.


7. CSV
Text file에 data를 저장하는 storage engine이다. 저장된 data file을 MS Excel이나 OpenOffice Calc같은 spreadsheet에서 열 수 있다. Index를 지원하지 않고, NULL도 저장할 수 없다.
 이거... 성능만 나쁘지 않다면 꽤 유용하게 쓸 수 있지 않을까요?!?! 이걸 어떻게 써먹을지 궁리를 좀 해봐야 겠습니다. 그리고 성능이 얼마나 나오는지도 확인해봐야 겠죠?


이상 너무 간단하지만, MySQL Storage Engine들에 대한 정리를 마칩니다. 영문 메뉴얼을 좀더 읽어보고, 실제로 Test도 해본뒤에 좀더 유용한 자료를 만들면 다시 올리겠습니다. 그럼 이만...


참고 자료
MySQL Documentation: MySQL Reference Manuals
MySQL Korea

 작년에 다녀왔던 "SQL Unplugged : 괴물이야기" 컨퍼런스에서 SQL Server에 대한 다양한 경험을 할 수 있었고, 이후 운영중인 SQL Server를 좀더 잘 운영하려고 노력하게 되었습니다. 튜닝 공부를 위해 주말 과정을 듣기도 했고, 시중에 나와있는 책도 찾아보게 되었구요. 그래서일까요? 아래 화면을 보게 되었을때 참 반가웠습니다.

"올해에도 하루라는 시간이 아깝지 않을 컨퍼런스가 열리는구나!!" 고맙습니다. 수고하셨습니다.
자세한 후기는 나중에 정리해서 올리겠습니다.




아래 글 링크는 작년에 SQL Unplugged 첫번째 컨퍼런스 참석 후기입니다. 
2010/06/14 - [IT 기술/Database] - SQL Unplugged "괴물 이야기" 참석 후기


 DBMS를 운영하다보면 종종 DB 복제, 혹은 특정 data의 동기화를 해야할때가 있다. 동일한 DBMS라면 그것도 시장에 잘 알려져 있어서 확실한 3rd party 복제 툴이 있거나, 혹은 한 두개 정도의 테이블만 복제/동기화 작업을 해줘야한다면 큰 문제가 아닐것이다. 허나 여러 종류의 DB를 사용하다보면, 그것도 시장에 널리 퍼지지 않았거나, 국내에서만 사용하는 DB라는 이유로 확실한 3rd party 툴이 없다면... 아마 저처럼 고민에 빠지게 될겁니다.
 제 고민의 원인에 대해서는 제가 앞에 작성했던 글들을 보시면 아시게 될겁니다.
2010/06/16 - [Database] - Tibero4 migration 모험기 (4) 중간정리 : Oracle DBA의 Tibero 사용 후기
2010/05/07 - [Database] - 국산 DBMS. TmaxData Tibero TAC의 좋은점과 아쉬운점.
2010/02/25 - [Database] - [이기종 DB간 Data 공유] MS-SQL에서 Openquery를 사용할때 문제점.
2010/02/01 - [Database] - Tibero4 migration 모험기 (3) Index rebuild 기능
2010/01/28 - [Database] - Tibero4 migration 모험기 (2) tbAdmin에 대해서
2010/01/07 - [Database] - [이기종 DB간 Data 공유] MS-SQL에서 Oracle에 있는 Data 가져와서 동기화 맞추는 기능 구현
2009/11/23 - [Database] - Tibero4 migration 모험기 (1) 사용자 정의 함수 사용시 경험한 묘한 버그
아~ 꽤 많군요. 걍 눈에 띄는것들만 선택한 건데...

 DB 복제(Replication), Data 동기화(Synchronization), Change Data Capture(CDC)... 뭐 이런 식으로 불리거나 비슷한 단어들로 묘사되는 툴들이죠.
 Oracle만 혹은 Oracle만큼 시장에 많이 알려진 DB2, MySQL, SQL Server, Sybase 등의 DBMS들, 심지어는 국내에서는 잘 쓰지 않는다고 알려진 Postgresql, FireBird까지도 지원하는 툴이 있는데, 저에게는 TmaxData Tibero라는 복병이 있습니다. 아시다시피 국산 소프트웨어이며, Oracle의 문법 체계를 그대로 적용하여 Query, Procedure 등을 개발할 수 있는 등의 많은 장점을 지닌 제품입니다.
 문제는 Tibero를 지원하는 툴들이 거의 없다는겁니다. NHN의 Cubrid가 오픈소스 프로젝트를 열고, 많은 개발자, 사용자들을 끌어들여서 Pentaho에서 JDBC를 이용하여 접속을 가능하게 하는 문서(블로그)가 검색되는 등의 성과를 올리는 것과는 반대로 "Orange for Tibero"외의 성과가 없는게 Tibero측의 아주 큰 약점입니다.
 물론 TmaxData에서는 자사의 Tibero와 함께 DB복제 솔루션인 ProSync와 ETL 솔루션인 ProETL이라는 제품도 판매하고 있습니다만, 아직 제약이 많습니다. Oracle-to-Tibero 복제는 이상없이 잘되는데, Tibero-to-Tibero 복제에서 문제가 생겨서 도입하려다 중지한 상태입니다. 뭔가 남들과 조금 다르게 구성하면 잘 안되는게 생기네요.

 이 모든것을 뒤로하고...

지금 고민은 "오픈소스 ETL/BI 솔루션 중에서 어떤 제품을 사용하는게 좋은가?"입니다. 음... 어떤게 좋을까요?
고민되네요.

Tibero4 migration 모험기 (4) 중간정리
Oracle DBA의 Tibero 사용기
 사용기나 감상문 정도로 적으면 될걸 굳이 모험기라는 조금은 부정적인 의미의 단어를 사용한건, Tibero라는 생소한 제품으로의 이전이 제게는 모험에 가깝다고 생각되어서입니다. 아주 주관적인 얘기니까 혹시 티맥스 관계자분들이 보시면... 걍 얘가 겁이 많구나... 이 정도로 생각하시면 됩니다. 현재 Tibero를 아주 잘 사용하고 있습니다. ^^

 그동안 Oracle을 사용하다가 Tibero RDBMS로 이전을 하기로 결정이 내려졌고, 현재 하나의 시스템을 제외하고는 Tibero로 이전을 하였습니다. 처음 Tibero를 접했을때는 너무 자료가 없고, 폐쇄적이라 테스트 해보기 힘들었다는게 문제였고, 실제 서비스에 일부 사용하고 있는 현재는 타업체의 DB, 솔루션과 함께 사용할때 생기는 다양한 문제점의 원인 파악 및 해결이 어렵다는게 가장 큰 문제입니다. 서두에 이미 결론을 내버려서 이 글을 끝까지 읽지 않으실지도 모르지만, 도입 결정 후 시스템 이전 과정과 서비스 과정에서 생긴 일을 하나씩 얘기해보려 합니다.

--------------------------------------------------------------------------

 * Tibero 도입을 결정하다.
 제가 이전에 블로그에 남겼던 글을 읽으셨다면 어느 정도 감을 잡으셨겠지만, Tibero 도입의 결정적인 이유는 다음과 같습니다.
첫째, Oracle RAC 도입 가격에 비해서 아주 저렴한 가격에 Shared Disk 방식의 Cluster DB를 도입할 수 있다.
둘째, Oracle에서 사용하던 Query, Procedure, Function 등이 수정없이 Tibero에서 사용할 수 있다.
셋째, 필요한 기능 추가 및 시스템 에러에 대한 빠른 대응 가능(국내에 연구 개발을 담당하는 조직이 있어서 가능한거죠.)

 위의 세가지 이유로 도입이 결정되었었습니다.

2010/02/18 - [Database] - DBA의 고민 (1) 고성능, 고가용성 시스템 구축. 안정성과 성능의 두 마리 토끼를 잡아야 하는데... ㅜㅜ
 위의 글을 보시면 왜 RAC같은 Cluster DB 제품을 도입하려하는지에 대한 내용이 들어 있습니다.

--------------------------------------------------------------------------

 * 테스트와 이전 작업을 진행하다.
도입이 결정되고는 내부 테스트와 이전 작업이 진행되었습니다. 작업 중 Oracle과는 다른점이 여러가지 발견되었습니다.

 [다르긴 하지만 크게 문제는 없어서 넘어간 점들]
첫째, 리스너는 하나 밖에 사용할 수 없다. 정책적으로 서비스나 솔루션별로 서로 다른 리스너를 사용할 수 없습니다.
둘째, log file들이 저장되는 위치를 마음대로 바꿀수 없다. Oracle에 비해서 자유도가 떨어지더군요.

 [문제가 있지만, 아직 패치가 되지 않은 점들]
첫째, Index rebuild를 할때 저장되는 Tablespace를 바꿀 수 없다. 여기에 관해서는 제가 예전에도 글을 올렸던 적이 있습니다. 2010/02/01 - [Database] - Tibero4 migration 모험기 (3) Index rebuild 기능

둘째, 서로 다른 Tibero instance간에 Materialized View를 생성해서 쓰면 성능 문제가 생길 수 있다.
  저희가 Materialized View(이하 M-View)를 사용하면서 격은 문제입니다. M-View에는 Fast라는 옵션을 줄 수 있습니다. 아시겠지만, 이 옵션을 쓰면 원본 Table에서 변경된 Data만 가져와서 M-View에 적용을 해줍니다. 이러면 M-View의 Data 동기화 작업 시간을 줄여주고, CPU 부하도 줄여주고... 뭐 이런저런 장점이 있습니다. 그런데 문제는요  동일한 인스턴스에서 M-View를 생성하면 Fast 옵션을 줄수 있는데, 서로 다른 티베로 인스턴스에서 DB Link를 이용해서 M-View를 생성하면 Fast 옵션을 줄 수 없다는겁니다. 어쩔 수 없이 Force 옵션을 주고 생성을 하게 되는데, 이러면 아카이브 파일이 엄청나게 쌓이더군요. M-View를 Refresh할때 마다 대량의 아카이브 파일이 생겨서 운영하기가 힘들 정도였습니다. 언제 패치가 나올지 확답을 받지 못한 상태입니다. 혹시 M-View를 많이, 그리고 여러 DB Instance에서 운영하시는 분들은 참고하시길 바랍니다.


--------------------------------------------------------------------------

이건 tbAdmin 사용자들을 위한 팁입니다.

* tbAdmin에서의 PSM 실행
 Oracle에서 DBMS_JOB 패키지를 사용하여 job을 설정하죠. Tibero에서도 동일하게 job을 설정합니다. 문제는 tbAdmin(TmaxData에서 Tibero client로 배포하는 이클립스 기반의 프로그램입니다.)의 sql 편집창에서 해당 PSM(Oracle의 PL/SQL에 해당합니다.)을 실행시켜도 job이 설정되지 않습니다. 그렇다고 에러 메세지도 보이지 않습니다.
 해결 방법은 간단하더군요. SQL 편집창 말고 PSM 편집창이 따로 있습니다. 거기에서 실행시키면 잘 됩니다.


 TmaxData의 Tibero4로 migration을 진행하면서 알게된 몇가지 내용 중 Index rebuild에 대해서 얘기해보고자합니다. 기존에 사용하던 Oracle을 기준으로 하면... (제가 가장 잘 아는게 Oracle이라 이녀석이 기준입니다.) Index를 사용하다가 rebuild 해줄때 몇가지 옵션을 줄 수 있습니다.

SQL> ALTER INDEX IDX01 REBUILD ONLINE;
   * 기존의 인덱스를 계속 유지한채로 REBUILD하고, REBUILD가 끝나면 바꿔치기 하는 옵션이죠.

SQL> ALTER INDEX IDX01 REBUILD ONLINE TABLESPACE TS_IDX2;
   * REBUILD를 하면서 저장하는 TABLESPACE도 바꾸는 옵션이죠.


 사실 DB 관리를 하다보면 tablespace를 바꿔줄 일이 가끔씩 생깁니다. 그래서 Tablespace를 바꿀 수 있는 옵션은 아주 유용합니다. 그런데... Tibero4에서는 이를 지원하지 않고 있네요. ㅡ.ㅡ
[General syntax error]라는 오류가 발생합니다. Tmax에서도 지원하지 않는다고 하네요. 그런데, Tmax에서 제공하는 Tibero 관리/개발용 툴인 tbAdmin에는 인덱스 리빌드창(마법사??)에서 Tablespace를 선택할 수 있도록 되어있습니다. 혹시나 해서 실행시켜보니까 똑같은 오류가 발생하네요.


 MS-SQL에서 Oracle에 있는 Data에 접근하기 위한 방법으로 Openquery라는걸 소개한 적이 있죠.
기본적으로 제공하는 기능이라 좋긴 하지만 동적으로 쿼리를 만들어서 결과값을 받아올수 없다는 얘기를 한 적이 있습니다. 그렇게 되면 WHERE절 조건을 정확하게 줄 수 없으니 오라클 DB에 부하를 많이 주게 되겠죠.
저도 이렇게 알고 서비스 중인 MS-SQL과 Oracle 사이에 Data 동기화 프로시져를 만들었었습니다.
그런데....

 웬걸...

 회사에서 사용중인 MS-SQL 2005에서 혹시나 하는 마음에 문자열 변수에 커서를 정의하는 문장까지 포함해서 동적으로 쿼리를 만들어 주고, 커서를 열었더니... 결과 값이 정상적으로 나오네요. 앗싸~ 가오리~

아래와 같은 방식으로 처리하니까 동적으로 쿼리문장을 만들어서 실행시키고 결과값을 커서에 받아서 사용할 수 있습니다.


DECLARE @QUERY_STRING VARCHAR(1000)
DECLARE @CODE        VARCHAR(30)
SET @CODE='SUPERCODE'
DECLARE @USERNAME VARCHAR(50)

SET @QUERY_STRING = 'DECLARE ORA_CUR CURSOR FOR
                     SELECT USERNAME
                         FROM OPENQUERY(ORA_DB, ''SELECT USERNAME
                                FROM USER_INFO
                               WHERE CODE='''''+@CODE+''''' AND USER_FLAG=''''N'''' '') '

EXEC (@QUERY_STRING)
OPEN ORA_CUR
FETCH NEXT FROM ORA_CUR INTO @USERNAME

WHILE @@FETCH_STATUS = 0
    BEGIN
    INSERT INTO dbo.USER_INFO(USERNAME)
    VALUES(@USERNAME)

    FETCH NEXT FROM ORA_CUR INTO @USERNAME
  END;

CLOSE ORA_CUR

DEALLOCATE ORA_CUR

 [Power*Architect Data Modeling & Profiling Tool]라는 툴을 아십니까? 흔히들 알고 있는 ERWin과 비슷한 모델링 툴이죠. 큐브리드 홈페이지에 Power*Architect에서 큐브리드를 사용하는 법이 소개된 글이 있어서 링크를 겁니다.

 원문보러가기 : Power*Architect 에서 CUBRID 사용하기

.소개: 본 문서는 보다 편리하게 CUBRID를 사용할 수 있도록 사용자 중심의 편의성 및 기능을 제공하기 위한 데이터 모델링 도구인Power*ArchitectJDBC를 이용하여 연결하는 방법을 소개합니다.

- 예전에 한번 사용해보려다가 모델링과 모델링 툴에 대한 이해 부족과 영문 메뉴얼에 좌절해서 접었던 적이 있었는데, 이렇게 문서도 올라오고 하니... 다시한번 사용해볼까 합니다. ^^;
 자동화는 관리자든, 개발자든 공통적으로 중요한 일이죠. 이번에 IBM DeveloperWorks에 "손 쉬운 데이터베이스 마이그레이션"이라는 제목의 글이 올라왔습니다. 흠... LiquiBase라는 오픈소스 소프트웨어를 이용해서 데이터베이스 변경 관리하는 법을 소개하고 있네요. 흥미로운 글입니다.

원문 : 사람을 위한 자동화: 손 쉬운 데이터베이스 마이그레이션

데이터베이스는 종종 그것을 기반으로 하는 애플리케이션과 어긋난 상태로 존재하는데, 이로 인해 데이터베이스와 데이터를 안정된 상태로 끌어내는 것은 관리에 있어서 상당한 도전 과제가 됩니다. 사람을 위한 자동화 이번 기사에서는, 자동화 전문가 Paul Duvall이 오픈 소스 LiquiBase 데이터베이스-마이그레이션 도구를 사용하여 데이터베이스와 애플리케이션의 변경 사항을 관리할 때 발생하는 고통을 줄이는 방법을 보여줄 것입니다.

수년간 내가 일했던 애플리케이션들은 대부분 다량의 데이터를 관리해야 하는 엔터프라이즈 애플리케이션이었다. 그런 프로젝트에서 일하는 개발 팀은 보통 데이터베이스를 애플리케이션과는 완전히 별개의 것으로 취급한다. 이는 때때로 데이터베이스 팀과 애플리케이션 개발 팀으로 나뉘어 있기 때문이거나, 단순하게 팀이 그런 식으로 일을 하기 때문일 것이다. 두 방법 모두 다음과 같은 결과를 초래할 수 있다.

  • 데이터베이스에 변경 사항 직접 반영하기
  • 데이터베이스 변경 사항을 다른 팀원과 공유하지 않기
  • 일관되지 않은 방법으로 데이터베이스나 데이터 변경 적용하기
  • 데이터베이스 버전을 다음 버전으로 변경하는 관리를 비효율적으로 손수 다루기

개발자들이 데이터 변경 사항을 제대로 인지하지 못한 상태로 두는 비효율적인 상황이 발생한다. 게다가, 그들은 애플리케이션 사용자가 데이터 불일치나 충돌 문제를 경험하게 할 수도 있다.

그림 1은 소프트웨어 개발 프로젝트에서 흔히 사용하는 데이터베이스에 직접 변경을 가하는 방법을 보여준다. 직접 데이터를 변경하는 방법은 불안하고 에러가 발생할 여지가 많다, 그리고 방금 한 것을 되돌리는 걸 어렵게 하며 시간 흐름에 따라 데이터베이스에 어떤 변화가 있었는지 그 히스토리를 분석하는 것도 힘들다. 예를 들어, DBA가 한 건의 조회 데이터를 변경해야 한다는 것을 기억하고 있을지 모른다. 하지만 한 개발자가 나중에 이 데이터를 같은 테이블에 넣어야 한다는 것을 깜빡할 수도 있다.


+ Recent posts