database.sarang.net
UserID
Passwd
Database
DBMS
MySQL
PostgreSQL
Firebird
Oracle
Informix
Sybase
MS-SQL
ㆍDB2
Cache
CUBRID
LDAP
ALTIBASE
Tibero
DB 문서들
스터디
Community
공지사항
자유게시판
구인|구직
DSN 갤러리
도움주신분들
Admin
운영게시판
최근게시물
DB2 Tutorials 160 게시물 읽기
 News | Q&A | Columns | Tutorials | Devel | Files | Links
No. 160
[자료/IBM] Case Study : 리눅스에 DB2 포팅
작성자
문태준(taejun)
작성일
2001-10-23 23:33
조회수
6,469

[출처] http://www.kr.ibm.com/developerworks/linux/library/l-db2.html

 

 

IBM Korea : developerWorks : Linux zone

 

Linux 애플리케이션으로 데이터베이스 액세스 통합

 

컨텐츠 :

코드 기반의 특성상, 작은 경험도 유용하다

Linux 배포판이 모두 같은가?

테스트 그리고 테스트

유닉스와의 차이점

새로운 단계

참고자료

개발자소개

필자 소개

기사에 대한 평가

 

관련 dW 링크:

US 원문 읽기

 

IBM DB2 팀의 알려지지 않은 이야기

Jeanne Murray (jeannem@us.ibm.com)

developerWorks 직원

2000년 8월

 

대규모의 상용 제품을 Linux에 포팅하려면 기술력 및 인내력 뿐만 아니라 유모 감각도 필요하다. IBM DB2 팀원들의 이야기가 여러분에게 인사이트를 줄 수 있길 바란다.

 

많은 Linux 프로젝트와 마찬가지로, 최초의 DB2 포트 작업은 아무도 주목하지 않는 상황에서 진행되었다. 1997년 말로 거슬러 올라가서, IBM DB2의 프로젝트 팀에 있던 두 명의 Linux 팬인 Leo Comitale와 Peter Joot는 DB2 소스 코드 트리를 그들의 데스크탑 Linux 컴퓨터에 복사하였다가 여가 시간을 이용하여 컴파일링 작업을 했다.두 명 모두 IBM의 모든 제품에 대한 운영 체제별 코드를 다루는 운영 체제 서비스 컴포넌트 팀의 일원이었다. Linux 포트 팀의 팀장인 Susan Williams는 다음과 같이 말한다. "팀의 일원으로서 Leo와 Peter는 원본 포트 작업을 수행하는데 이상적 이였습니다. 말하자면 그들은 특정 플랫폼 코드를 지닌 DB2의 한 가지 구성 요소라고 할 수 있습니다." Linux에 대한 관심과 자신들의 운영체제에 대한 전문 지식이 결합되어 성공적인 결과를 낳았다. 1998년 5월, 그들은 Linux에 컴파일, 링크 및 실행 작업을 하는데 까지 성공하였으며 드디어 승인 테스트를 통과할 단계까지 도달하게 되었다.

 

그러는 동안, Linux는 시장에서 힘차게 전진하고 있었다. DB2 마케팅 팀은 그들 제품을 Linux용으로 제공할 것을 신중하게 검토하기 시작하였다. 또한 개발팀에 기획을 평가해 줄 것을 요청하였다. 이 팀은 보이지 않는 곳에서 코드를 만들어 낼 수 있었고, Susan이 기술적인 책임을 맡게 되었다.

 

Susan은 다음과 같이 말했다. "내가 맡은 일은 기본적으로 코드를 제품화하는 작업입니다. 회기 테스트(regression test), 시스템 테스트(system test), Nightly Build 작업, 그리고 버그를 수정하는 일입니다. 승인 테스트를 통과하는 것 만으로 모든 것이 잘 작동된다고 할 수는 없기 때문입니다." Linux의 DB2 베타 릴리스는 1998년 초에 Slashdot에 발표되었으며, 발표를 결정한 지 불과 2개월 후의 일이었다..

 

대규모 상업용 개발 프로젝트의 일원으로 참여한 경험이 있는 사람이라면 이 그룹에서 그렇게 단시일 내에 포트를 생산할 수 있었다는 사실에 경의를 표할 것이다. Linux 포팅 기획에 관여한 적이 있는 사람들은 누구나 프로젝트를 수행하면서 겪은 우여곡절을 이야기할 것이다(물론 앞으로 있을 도전적인 일은 물론이고).

 

코드 기반의 특성상, 작은 경험도 유용하다

Susan 팀은 포팅 기획에서 쌓은 경험을 이용하였다. DB2 UDB는 또한 AIX , Solaris, HPUX, SCO UnixWare 7, SGI IRIX, Numa Q, OS/2, Windows NT 및 Windows 95/98/2000에서 실행된다. 더구나 DB2 소스 코드의 98%는 모든 플랫폼에 공통 사항이다. 모든 플랫폼의 특정 호출은 플랫폼 특정 코드가 이 구성 요소와 분리되게 운영 체제 서비스 계층을 통하여 구성된다. 따라서 5000 이상의 소스 코드 파일 중 단지 200 내지 300 개 파일을 Linux 포트 용으로 변경하는 것이 필요하다.

 

빌드 환경 역시 속도를 낼 수 있는 구조를 갖추고 있다. 각 플랫폼은 컴파일 옵션, 링크 옵션 및 공유 라이브러리를 구축할 스크립트 당 한 개의 파일을 포함한다. 또한 각 플랫폼에는 사용 경로를 설치할 여러 유틸리티와 헤더 파일 찾을 위치, 지원 기능의 종류 등과 같이 각 플랫폼에 대한 옵션이 있는 여러 구성 파일도 포함된다.

 

"모든 빌드 스크립트는 Perl로 구성되어 있고, 또한 우리는 GNU make를 사용하기 때문에 이식성이 매우 높습니다." 라고 Susan은 말한다. " Peeter와 Leo가 쉽게 시작할 수 있었던 것은 부분적으로 이러한 이유 때문입니다. 그들은 소스 트리를 그들의 Linux 컴퓨터에 복사하였는데 우리가 사용하는 표준 Perl 툴로 컴파일링을 시작하였습니다. 세 개의 다른 구성 파일에 설정하고 몇 개의 다른 구성 파일에 3~4개의 ifdef를 추가하는 식으로 일을 계속하면 그렇게 오래 걸리지 않습니다."

 

그들은 매일 밤 한 번씩 각 플랫폼에 대해 처음부터(from scratch) 제품을 빌드했다. 1GB의 RAM과 1GB SWAP을 지닌 PC 서버 704(4 x PPro 200)에서 DB2 엔진을 빌드하는데 약 두 시간 반이 소요되었다.

 

Linux의 첫 베타 버전을 위하여 (이것은 그때 당시 DB2 버전 5.2) 그들은 정규 코드 제어 프로세스로부터 벗어나 별도의 코드 트리를 유지하였다. GA 레벨 코드는 이미 릴리스된 상태이므로 Linux 베타도 Web에 공개되었는데 첫 주 동안 10,000회 다운로드를 기록하였다. 1999년 7월까지 DB2 버전 6.1은 첫 공식적인 Linux GA코드가 되었으며 70,000회 다운로드를 기록하였다.

 

Linux 배포판이 모두 같은가?

찬밥 신세를 면치 못하던(Skunkworks) 포트 시기에는 그들은 RedHat 5.1용 베타 릴리스를 빌드하였다(그 당시의 최신 버전). 기술 담당자인 Susan은 다음과 같이 말한다. "우리는 기본적으로 2개월만 시간이 있어 다른 배포판에서 테스트할 시간적 여유가 없었습니다."

 

"내부적으로 신속히 입수하는 것이 불가능했기 때문에 직접 상점에 가서 배포판을 구입했습니다. 그러나 지금은 우리는 테스트하고 있는 4개의 주요 배포판용 iso CD이미지가 내부 ftp 사이트에 올려져 있습니다." DB2 버전6.1은 Linux에 제공된 첫 번째 "실질" 버전이었다. 그들은 그 버전을 RedHat 5.1, 5.2와 6.0, Turbo Linux 3.01, SuSe 6.0과 Caldera OpenLinux 2.2에서 테스트하였다.

 

그들의 주요 목표는 배포판에 독립적인 제품을 만드는 것이다. 그렇게 하여 각 배포판을 위해 별도의 바이너리를 적재할 필요가 없도록 하는 것이다. "두 번째 목표는 그들의 제품이 비주류 배포판에서도 실행되게 하는 것입니다. 그들은 제품을 실행시키기 위해 커널을 다시 컴파일하는 일이 없기를 바라고 있습니다." 라고 Susan은 말한다.

 

DB2 엔진은 다음 선행 조건(pre-reqs)을 만족하는 어느 배포판에서도 실행된다 :

 

커널 2.0.35 또는 그 이상 또는 2.2 (DB2 버전 7.1용 2.2.12)

 

glibc 2.07 또는 그 이상 (DB2 버전 7.1 용 2.1.2)

libstdc++ 2.8.0 (DB2 버전 7.1 용 2.9.0)

pdksh, 설치와 CLP 용으로 필수

rpm, 설치 용 or higher (2.1.2 for DB2 Version 7.1)

그들은 베포판 교차 테스트에 약간의 미스터리가 있기 때문에 이 선행 조건 목록을 만드는데 다소 어려움이 있었다. 대부분의 문제는 설치 프로그램에서 발생했다. 예를 들면 pdksh는 설치에는 필수적이나 대부분의 배포판에서 디폴트로 설치되어 있지 않았다. 대부분의 배포판은 libstdc++2.8을 포함하지 않았다. 커스 라이브러리(curses libraries)는 배포판 간에 약간의 차이가 있으며 KDE, Gnome와 xterm에서 실행되는데 문제를 발생시켰다. rpm 이름은 모든 배포판마다 동일하지 않았으며 따라서 rpm을 선행조건으로 하는데 어려움이 발생하였다. 이것을 해결하기 위해 glibc를 위한 속 빈(dummy) rpm을 포함시키고 그것을 문서로 제공했다. DB2 버전 7에서는 선행 조건에 필요한 모든 것을 rpm으로 패키징 해 놓았다.

 

근본적인 문제 중 하나는 glibc 레벨에서의 문제이다. "우리는 DB2 버전6.1 베타버전을 웹상에 공개했는데, RedHat 6.0에는 glibc 2.0과 2.1간의 curses라이브러리의 바이너리의 비호환성 때문에 설치가 되지 않았습니다." 라고 Susan은 말한다. RedHat는 DB2 릴리스 6.1 버전이 발표되기 한달 전에 glibc 2.1과 함께 출시되었는데 DB2를 그게 맞게 변경하기에는 너무 늦었던 것이다. "glibc 버전은 바이너리 호환 가능하도록 되어있으나 미묘한 차이가 발생하여 문제가 되었습니다. 엔진은 잘 작동하였으나 6.1 버전을 glibc 2.1 시스템에서 실행하는 경우 어떤 제품의 기능은 작동이 제대로 되지 않았습니다." 그들은 또한 메모리 손상을 발견하였는데, 이것은 자체 코드의 버그로 결정하였다.

 

문제는 glibc 2.0이 libc 5 (glibc의 원조)보다는 훨씬 나았고 모든 Linux 배포판은 이것을 사용해야 한다는 것이었다. Susan은 다음과 같이 설명한다 "DB2를 특정 배포판에 관계없이 작동되도록 하는 것이 목적이었기 때문에 배포판에서 사용되고 있는 것을 사용해야만 했습니다." 그러나 2.0 레벨은 개발 릴리스로, 2.1은 제품 릴리스로 간주되었다.

 

개발 릴리스의 'use-at-your-own-risk (위험부담을 가지고 사용하기)'라는 아이디어는 해커한테는 괜찮으나 제품용은 일반적으로 좀 더 테스트 환경에 대한 제어가 필요하다. "새 주요한 릴리스의 생산 사이클은 1년에서 2년 사이 입니다." 라고 Susan은 말한다. "그러나 주요한 Linux 배포판은 매 3 개월에서 6 개월 만에 새 릴리스를 발표합니다. 우리가 하나의 배포판에 대해 완벽한 테스트를 끝낸 시점에는 이미 새로운 배포판이 나와있는 상태입니다."

 

위험 부담을 줄이기 위하여 그들이 사용한 하나의 전략은 특정한 커널 버전에 대한 의존성에서 탈피하는 것이다. 대부분 버전 6.1 테스트는 단일 CPU 기계 용 커널 레벨 2.0.35/36 및 SMP 기계 용 2.2.2에서 수행되었다. 버전 7 테스트는 2.2.20-13에서 수행되었다.

 

테스트, 그리고 테스트

테스트 단계는 여러 가지 이유로 철저하고 힘든 작업이다. " 새로운 포트를 구성하는데 있어서 가장 큰 비용은 테스트 기획입니다." 라고 Susan은 말한다. " 새로운 포트를 분류하는 것은 보통 몇 명이 수 개월간 컴파일하고 링크하는 노력이 필요하며 테스트하는 데에 장소 불문하고 30명에서 60명까지의 수 개월간의 노력이 필요합니다."

 

그들은 무작위 테스트 사례 배포판을 사용하여 회기(regression) 테스트를 4개의 다른 배포판에서 하였다. Susan은 다음과 같이 말한다 "각 배포판 당 한 개씩 4개의 컴퓨터를 사용하였습니다. 우리는 테스트 버킷(bucket)을 무작위로 컴퓨터를 통해서 배포했습니다. 이 작업은 자동 회귀 툴을 사용하여 쉽게 할 수 있었습니다." 완벽한 자동 회귀 사이클은 일주일이 걸린다. 그리고 나서 그들은 무작위 테스트 버킷 배포를 매주 반복하였다. 시스템 테스트는 모든 배포판에 대한 스트레스 테스트 및 기타 기능에 대한 무작위 건전(sanity) 테스트와 더불어RedHat 배포판에 대한 완벽한 테스트로 구성되었다.

 

"무작위"가 "제어되지 않음"을 의미하지는 않는다. 한 운영 체제의 다중 레벨에 영향을 미치는 테스트 전략이라는 광범위한 관점으로부터 다시 다중 운영 체제를 통하여 교육적인 판단을 내려야 한다. "때때로 우리는 운영 체제를 통하여 테스트를 반복합니다." DB2 시스템 검증 테스트 팀의 일원인Anumpa Mukherjee의 설명이다. " 예를 들면 NT 클라이언트에서부터 Unix 서버와 비교하여 Unix 클라이언트에서부터 Unix 서버의 원격 관리는 다른 문제에 부딪칠 수 있습니다. 그러나 모든 테스트를 지원하고 있는 모든 버전에서 이렇게 반복할 수는 없는 것입니다. 그것은 영원히 불가능합니다."

 

40명의 테스트 요원으로 구성된 시스템 검증 테스트 팀은 호스트 플랫폼을 제외한 모든 플랫폼에 대하여 DB2 Universal Database의 고객 시뮬레이션 유형 테스트를 실시한다. 그들의 전략에는 진행중인 작업에 대한 효율성을 평가할 수 있는 지속적인 분석이 포함된다. 예를 들면, 유틸리티 테스트를 하는데 있어서 모든 플랫폼을 통하여 동일한 테스트 시나리오를 실행한다. 하지만, 우리가 발견한 사실은 대부분 각 플랫폼에서 동일한 버그가 발견된다는 것이다. 특정한 플랫폼에만 해당되는 버그의 수는 아주 낮았다. 따라서 가장 최근 릴리스에서 전략을 약간 바꾸어 적용범위를 분리하였다. 하나의 시나리오가 1, 3, 5의 항목을 테스트하면 다른 시나리오는 2, 4의 항목을 테스트한다. 따라서 플랫폼을 통하여 약간의 반복은 불가피하지만 실지로 하고있는 일은 다른 유틸리티와 데이터 관리 패킷을 테스트하는 것이 된다. 그리고 그렇게 하면 작동이 원활할 것이다.

 

Linux에서 테스트하는 과정에서 그들은 새로운 문제에 부딪쳤다. Susan은 다음과 같이 말한다 "서로 다른 배포판에 너무 의존적이며 또한 변화가 너무 빠르기 때문입니다. 우리가 직면한 도전 중 하나는 모든 것에 자바를 이용하기 때문에 여러 Linux 배포판의 JDK에 대한 지원에 대한 문제가 있었습니다. 또 다른 도전은 DB2가 약 20여 개 언어로 사용 가능하기 때문에 Linux의 여러 언어에 대한 지원 문제입니다. "

 

"아시아 태평양에서 사용 가능한 Linux 배포판은 일본어 지원만 가능할 뿐입니다. 혹은 일본어는 지원되지만 올바른 수정이 이루어진 JDK를 구할 수 없습니다. 우리의 대부분의 툴은java로 만들었으며, 지원상의 문제가 이슈가 되어왔습니다. 이것은 우리에게는 새로운 도전과제 입니다. 설정과 구성은 조금 다른 문제이며 조금 새로운 문제이기도 합니다. Unix 문제도 아니고 Intel 문제도 아닙니다. 그러나 구성에 대해서는 그러한 제한이 극복된 것으로 생각합니다." 라고 Susan은 말한다.

 

유닉스와의 차이점

수년간 DB2 팀원들은 다중 플랫폼을 통하여 상당한 기술을 축적했다. 그러나 Linux 환경은 그들의 기술 세트에 새로운 차원을 추가하였다. Linux에서 개발과 테스트는 사람이 기술을 재빨리 개발하여 변화하는 환경에 대응해야 한다는 점에서 하나의 도전이었다. Susan은 그녀의 팀이 작업한 기타 Unix 포트와 비교하여 Linux와의 심각한 차이점을 강조한다.

 

"첫째, Unix는 회사로부터 많은 엔지니어링 지원을 받습니다." 라고 말한다. 하드웨어 판매를 포함한 여러 이유로 인해 판매인은 문제를 해결할 동기가 주어지며 그 일을 도와줄 엔지니어링 팀을 지원한다. "Linux같은 경우, 뉴스그룹을 통해 정보를 얻거나 스스로 해결해야만 했습니다." 그녀는 Slashdot의 정규 구독자이기도 하다(참고자료).

 

둘째, 다중 배포판에서의 테스트는 훨씬 더 어려움을 가중시킨다. "예를 들면, 우리는 보통 Solaris의 한 개 또는 두개의 버전, HP UX의 한 개의 버전 등 다수의 유닉스를 지원하지만 결국 큰 차이는 없습니다. 근본적으로는 동일한 패키지이기 때문입니다. 그러나 Linux의 경우는 배포판마다 서로 다릅니다."

 

셋째, 휘발성(volatility). "커널이 매달 한 번씩 변경되므로, 비주류 배포판(변경된 커널을 즉시 적용하는)에 많이 의존해야 합니다."

 

"훌륭한" Linux 개발자와 테스트 요원이 되려면 어떤 종류의 기술을 가진 사람이 되어야 하는가? " 이 포트 팀의 경우 DB 기술보다는 Linux 기술을 더욱 많이 소유한 사람들입니다." 라고 Susan은 말한다. "예를 들자면, 커널 메일링 리스트의 사람들 앞에서 자신의 입장을 고수할 수 있을 정도는 되야 합니다." 그녀는 4년 전, 대학 졸업 후 IBM에 합류할 때, 자택 컴퓨터에 Slackware Linux를 설치하고 "Running Linux"(참고자료)라는 책으로 Linux 기술을 연마하기 시작했다. " 나는 아직 그 책의 초판을 가지고 있는데 정말 구식 판이 되었으나 아직까지 Linux에 대한 최고의 책이라고 생각합니다."

 

Anumpa는 테스트 요원으로서의 자질에 대해 말한다. 문제를 판단하는 기술은 물론 중요하다. "문제를 보고 즉각 왜 이러한 일이 발생했는지에 대해 네 가지 이유를 생각하고 그 이유를 도출해내는 능력이 필요합니다. 예를 들면 플랫폼 X가 Y기능을 수행하는데 문제가 있다고 하면 다른 구축 단계에서도 동일한 문제에 부딪히는가, 다른 구축 단계에서도 동일한 문제에 직면한다면 문제 해결의 다음 단계에 진입합니다. 그러나 문제가 다음 연속적인 단계에서 사라져 버리면 그것으로 무엇인가 고쳐졌다는 것을 알게 됩니다. 큰 그림을 보고 문제가 어디서 발생하는지를 알 수 있는 능력 그것이 정말 중요한 열쇠이죠."

 

두 번째 중요한 기술 이자 보다 더 실질적인 특성은 이것저것 다루어 봐야 한다는 것이다. "'이렇게 해보면 어떻게 될까' 라고 말할 수 있는 사람이 되어야 합니다." Anumpa는 다음과 같이 덧붙여 말한다. "종종 기대하지 않았던 결과를 일시적 기분에서 시도하여 얻게 되는 경우도 있습니다. 우리 팀에 하계 실습생을 교육하다 보면 가끔씩 그들은 '좌절감을 느낍니다. 테스트를 끝내지 못할 것 같아요'라고 말하곤 합니다. 그러면 나는 ' 바로 그것을 깨닫는 것이 중요하죠' 라고 대답합니다. 또한, 그들이 '계속 버그만 실행하고 있습니다' 라고 말하면 나는 '그 점이 중요한 것이라니까요' 라고 대답합니다. 한꺼번에 모든 것을 얻어내고 끝내려는 사고방식과는 다르죠. '나는 이러한 문제가 천천히 발생하리라고 예상하고 있고 한 단계씩 모든 것을 해결하려고 생각한다'라고 말할 수 있을 정도의 사고 방식을 전환하기는 처음엔 매우 어렵습니다."

 

세 번째는 스트레스 받는 상황에서 협조적으로 일하는 능력이다. " DB2 시스템 테스트 팀은 중요한 경로에 있습니다. 그 이유는 이 팀은 개발 사이클을 마무리 짓는 최종 큰 작업이기 때문입니다." 라고 Anumpa는 말한다. "스트레스를 받는 여러 상황에서 많은 동료와 함께 일하는 것에서 스트레스를 다루는 법을 익혀야 합니다."

 

새로운 단계

Linux가 발전하면 제품 개발 커뮤니티도 발전한다. 예를 들면 Java 저장 프로시져(Java stored procedure)와 같은 DB2 버전 6.1에서 가능하지 않았던 DB2 기능이 버전 7에서는 가능하다. Susan은 다음과 같이 말한다 "DB2 버전 5.2 및 6는 Blackdown JDK 1.1.7을 기반으로 했는데 Java 저장 프로시져만 제외하고는 다른 문제는 없었습니다. 버전 7에서 우리는 IBM JDK1.1.8을 사용하고 있습니다." 기타 예는 ADSM 백업 지원, REXX 지원, 또는 2단계 커밋(2-phase commit)이 있다. Susan은 다른 기능들이 Linux에 통합될 것이라고 예상하고 있다.

 

"지금까지 우리는 피상적 포트(shallow port)라는 것을 해왔습니다." 라고 Susan은 말한다. 이는 컴파일하고 테스트한 후에 문밖에 내놓았다는 의미이다. "현재 우리는 좀더 심층적인 포트를 시작하고 있습니다. 따라서 Linux에서 좀더 많은 커널 특징을 사용하고 이용할 수 있습니다."

 

예를 들면, 2.3 이전에 Linux 커널은 rawdisk I/O를 지원하지 않았다. 원본 디스크에서 테이블 공간을 작성하는 능력이 디스크의 신속한 액세스를 가능케 하기 때문에 그러한 기능은 데이터베이스 제품에 유용하다(그러한 점에서 DB2는 모든 기타 Unix, OS/2 및 NT에 대해 그와 같은 기능을 갖추고 있다). "여러 패치가 많이 있으나 우리는 패치 된 커널을 지원하지 않습니다." 라고 Susan은 말한다. "2.3 커널에 지원이 되고 있고 SGI 또한 2.2 커널(그들이 지원하는 커널)에 패치를 갖추고 있습니다. 따라서 우리는 이것을 조사하고 있습니다."

 

새 커널로 이용하고자 하는 것에는 증설된 메모리 지원도 있다."2.3 커널에서 16GB까지 메모리 지원은 버퍼 풀을 갖출 수 있게 되기 때문에 데이터베이스에 정말로 유용합니다." 라고 그녀는 말한다.

 

그들의 목표 가운데 하나는 커널에서 무엇이 이루어 지는지 좀 더 긴밀하게 추적하여 추가 기능을 잘 이용하자는 것이다. 최근까지 문제는 대역폭이 문제이다. 팀의 Linux 팀의 일원으로서 그녀는 혼자서 모든 것을 처리할 시간은 없다. "커널 개발에 좀더 집중하고 싶지만 DB2도 개발해야 하기 때문에 그럴 시간이 없습니다." 라고 설명한다. "커널 메일링 리스트를 계속 읽고 있지만, 실제로 참여할 시간은 없습니다." 팀에 인원이 추가되어 커널 개발에 좀 더 관심을 기울일 수 있기를 바라고 있다. 그녀는 Linux가 데이터베이스에 좀더 잘 작동하고 Linux Community와 긴밀히 일할 수 있기를 바라고 있다.

 

참고자료

 

IBM DB2 웹 사이트

Linux 설치 HOWTO - DB2 V7.1 : Linux 프로젝트 책자

Linux 실행하기 제 3판, 3rd Edition : Matt Welsh, Matthias Kalle Dalheimer, and Lar Kaufman 공저(O'Reilly: 1999)

Linux 및 Databases : 추가 참고자료 및 링크

UpsideToday의 Open source gold diggers look to databases : open source databases 의 진행사항에 관한 자세한 내용

Linux에서 상용 데이터베이스 시스템 사용하기

데이터베이스 평가 여부 site.

DB2 initiatives

Slashdot

개발자 소개

Susan Williams(susanwlm@ca.ibm.com.)는 DB2용 Linux 포트 기획을 이끌고 있다. 몬트리올에 있는 McGill 대학에서 생화학 학사 학위를 취득하였고 부전공으로 컴퓨터 과학을 공부하고 Waterloo 대학에서부터 컴퓨터 과학분야 인공지능과 컴퓨터 언어에서 석사 학위를 취득하였다.

 

 

Anumpa Mukherjee(anumpa@ca.ibm.com.)는 IBM 토론토 실험실에서 DB2 시스템 검증 테스트 팀을 관리한다. 12년 전 캐나다 온테리오주 킹스턴에 있는 Queen's 대학에서 전자공학 분야 응용과학 학사 학위를 받고 졸업 후 IBM에 입사하였다. 그녀는 응용 프로그램 개발자로서 DB2 제품 개발 팀의 개발자, 릴리스 관리자, 지금은 테스트 관리자로서 합류하기 전까지 호스트 기반 시스템에 관한 일에 종사했으며 DB2 기술을 연마하면서 시간을 보냈다.

 

 

 

필자소개

Jeanne Murray (jeannem@us.ibm.com)는 developerWorks의 직원이다. 10년 동안 IBM에서 소프트웨어 엔지니어로 일했다. IBM에 합류 전 그녀는 굴지의 컨설팅 회사에서 일했고 프리랜서 편집자 및 작가로 활동했다.

[Top]
No.
제목
작성자
작성일
조회
235DB2 UDB 성능 가이드
정재익
2001-12-17
7014
234Tablespace Performance Guide
정재익
2001-12-17
8744
233DB2 UDB Stored Procedure Builder 가이드
정재익
2001-12-17
8328
160[자료/IBM] Case Study : 리눅스에 DB2 포팅
문태준
2001-10-23
6469
158DB2 UDB 제품군 정의 [1]
이전건
2001-10-23
6148
157윈도우즈용 DB2 병렬 데이터 베이스(db2 EEE for windows)
이전건
2001-10-23
4757
148DB2 Connect Performance Tuning Hints [1]
정재익
2001-10-18
8067
Valid XHTML 1.0!
All about the DATABASE... Copyleft 1999-2023 DSN, All rights reserved.
작업시간: 0.054초, 이곳 서비스는
	PostgreSQL v16.1로 자료를 관리합니다