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 Columns 214 게시물 읽기
 News | Q&A | Columns | Tutorials | Devel | Files | Links
No. 214
가용성 측면에서 살펴본 DB2 Software
작성자
정재익(advance)
작성일
2001-11-29 00:02
조회수
13,595
첨부파일: biz_focus2.gif (5,022bytes)

가용성 측면에서 살펴본 DB2 Software

 

원본출처 : http://www-903.ibm.com/kr/software/library/biz_focus_attachment1.html

 

[목차]

 

DB2 소프트웨어

트랜잭션 및 쿼리 성능

효율적인 백업 및 복구 - 온라인과 오프라인

단일 포인트 오류 줄이기

재해 복구를 위한 효과적인 메커니즘

시스템 운영 그 이상의 것

DB2 UDB V.7의 고가용성

 

원문 보기 : http://www.db2mag.com/db_area/archives/2000/q4/ziko.shtml

 

DB2 소프트웨어

 

DB2의 가동이 멈추었다고 해서, 처리되던 모든 트랜잭션과 쿼리를 살펴볼 필요는 없다.

 

[그림 1]은 Data Manager가 백업을 가지고 있는 지 여부를 확인하는 3 가지 서로 다른 시나리오를 도해한 것이다. 가용성 분야에서는 이러한 과정을 페일오버(failover)라고 한다. 이제 시스템 오류가 발생할 경우, 페일오버를 실행하는 방법을 알아 보자.

 

시스템 가용성 향성을 위한 페일오버 시나리오를 처리하는 데엔 추가적인 소프트웨어가 필요하다. 일반적으로 e-비즈니스 시스템의 운영체제 제조업체에서는 이러한 페일오버 시나리오를 처리할 소프트웨어를 제공하고 있다. 만일 AIX 환경에서DB2 UDB를 운영할 경우, IBM의 HACMP(High Availability Cluster Multiprocessing)를 사용하면 된다. 만일 Windows NT나 Windows2000 환경에서 DB2 UDB를 가동하고 있다면, Microsoft Cluster Server를 사용하고, Sun Solaris 환경에서는 Sun Cluster를 사용하여 페일오버 시나리오를 처리하면 된다.

현재 IBM은 HP-UX 시스템의 페일오버 지원을 위해 휴렛팩커드의 HP-UX 시스템용 MC/Service Guardfmf 제공하고 있다. 여러 공급업체들이 [그림 1]에 나타난 페일오버 시나리오를 지원할 제품들을 공급하고 있다.

 

"상호 인계(mutual takeover)" 시나리오에서는 모든 노드들은 동등하며, 각각의 노드들은 지정된 노드(동료 : buddy)를 지원하게 된다. 각각의 DB2 노드들은 지정된 파트너 노드를 가지고 있으며, 각 파트너들은 시스템 오류가 발생할 경우, 지정된 파트너 노드를 지원하게 된다.

 

이 시나리오에서 페일 오버가 진행되는 동안 성능이 떨어지는 것을 목격할 수 있을 것이다. 이는 백업 노드가 백업을 처리할 때까지 한 노드의 작업이 다른 노드로 이동되기 때문이다. 이 시나리오에서 라이센싱은 문제될 것이 없다. 그것은 관련된 모든 노드들이 생산 및 페일 오버 노드로서 DB2 환경 내에서 움직이기 때문이다.

 

"휴면 대기(Idle standby)" 페일오버는 하나의 노드가 대기상태에 있으며, 시스템 실패 발생 시 작업을 위임받는다. 이 시나리오에서는 작업에 참여치 않은 노드가 시스템 오류가 발생할 때까지 대기하고 있으므로 전체 시스템 성능은 영향 받지 않는다. 사용자가 DB2 UDB Enterprise Editon(EE)을 운영하고 있을 경우, 비록 DB2 Enterprise Edition을 4웨이 SMP 박스 위에서 가동하고 있을 지라도, 하나의 프로세서는 휴면 노드로 할당해야 한다. DB2 UDB Enterprise Extended Edition(EEE) 환경에서 이러한 유형의 페일오버 지원 책을 구현하고 있다 하더라도 사용자는 휴면 노드에 대한 프로세서 할당을 잊어선 안된다.

 

"활성 대기(Active Standby)" 시나리오는 활성화 되어 있는 하나의 노드가 실패한 노드의 작업을 신속하게 위임받게 된다는 내용이다. 이 노드를 모든 노드에 대한 단일 지정 백업 노드라 한다. 지정 백업 노드가 작업을 수행하므로 시스템 성능에 영향을 미칠 수 있다. 하지만, 이러한 페일오버 구성은 하드웨어 자원 낭비를 막는 이점을 가지고 있다. 다시 말하면, 모든 노드들이 데이터 생산 작업에 참여하므로 추가적인 라이센싱 비용이 소요되진 않을 것이다.

 

 

[그림 2]는 페일오버 지원 소프트웨어의 작업 방식을 도해하고 있다. 이 그림에서 HACMP Heartbeat Monitor는 노드 작업 신호 모니터 역할을 수행한다. 노드의 작업 신호가 탐지되지 않을 경우, 백업 노드가 자동으로 작동하게 되고, 작업은 멈춤 없이 지속된다. 사용자는 노드의 중단 혹은 이상 상태를 알 수 없다. 보다 자세한 정보는 DB2 Administration Guide를 참조하라.

 

트랜잭션 및 쿼리 성능

 

가용성을 구성하는 데엔 시스템 확장성도 큰 기여를 한다. 확장성 여부를 체크할 수 있는 질문들 몇 개를 제시하면 아래와 같다:

 

시스템 사용이 증가할 때 데이터베이스가 어떻게 반응하는가?

 

다수의 동시 사용자가 데이터 웨어하우스에 쿼리를 날리게 되면 어떤 현상이 발생하나?

 

단 몇 분이면 처리할 쿼리에 몇 시간을 소비하다가 시스템 정지로 연결되지는 않는가?

 

고객들이 웹을 통해 트랜잭션을 처리할 때, 데이터베이스는 시의적절하게 요청된 트랜잭션을 처리하는가?

 

트래픽이 증가할 경우, 데이터베이스의 성능과 시스템 가용성에 어떤 영향을 미치는가?

확장성이란 시스템 성공 요인은 하드웨어 추가를 통해 증가하는 고객 요구를 충족시키는, 가용성의 또 다른 일면이다. DB2 UDB는 확장성을 지원하기 위한 많은 기능을 가지고 있으며, 이를 기반으로 가용성 향상에 많은 기여를 한다.

 

DB2 UDB EE 버전은 내부 파티션 병렬 체제(intrapartition parralelism)을 지원한다. 이 체제는 SMP 환경에서 증가하는 트랜잭션과 쿼리를 효율적으로 처리케 지원하는 기능이다. 내부 파티션 병렬 체제는 SQL statement segment를 병렬처리하는 데이터베이스 엔진의 능력을 참조한 것이다. 예를 들면, DB2 UDB 데이터베이스 엔진은 단일 SQL문으로 동시에 SELECT, SORT, 그리고 JOIN문을 처리할 수 있다. DB2 UDB EEE 버전은 확장성 있고 실질적인 이득을 제공하는 리니어(linear) 능력을 가지고 있어 다량의 트랜잭션 및 쿼리 워크로드를 감당할 수 있다.

 

DB2 UDB EEE 버전은 내부 파티션 병렬 체제와 함께, 상호 파티션 병렬 체제(interpartition parallelism)를 가지고 있다. 이 체제는 모든 로드에 걸쳐 병렬로 쿼리를 처리하는 DB2 기능을 참조한 것이다.

 

DB2 UDB EEE 환경에서 테이블의 열들은 시스템 운영에 참여하는 모든 노드에 할당되어 있다. 발생된 쿼리가 각각의 노드에 전달되어 노드 상에 있는 데이터로 병렬 작업을 하게 된다. 게다가 DB2 UDB EEE 버전에서 사용자들은 내부 파티션 병렬 체제 및 상호 파티션 병렬 체제를 동시에 사용할 수 있다.

 

DB2 UDB EE 버전은 쿼리를 처리하는 병렬 체제를 지원하며, 인덱스를 백업, 복구, 로드, 생성하는 각종 유틸리티들을 지원한다. DB2 UDB EEE 버전은 쿼리, 삽입, 업데이트, 삭제를 위한 병렬 체제를 지원하며, 가용한 모든 데이터베이스 유틸리티들을 지원한다.

 

이 외에도 DB2가 보유한 확장성 지원 기능은 여러 가지가 있다:

 

사용자는 데이터베이스에 입력되는 쿼리의 흐름을 제어하는 백-엔드 툴(DB2 Governor)와 프론트-엔드 툴(DB2 Query Patroller)들을 함께 사용할 수 있다.

(프론트-엔드 툴은 여러 서비스들이 데이터베이스 엔진에 도달하기 전에 서비스의 흐름을 막을 수 있다. 예를 들면, Query Patroller의 경우, Administrator 지정 크기 이상의 쿼리가 발생했을 때 이를 중지시킬 수 있다. 백-엔드 툴은 데이터베이스 엔진에 기반을 둔 툴이다. DB2 Governor는 우선순위를 변경시키거나 처리 시간이 오래 걸리는 서비스들을 중단시킬 수 있다.)

 

사용자들은 RAID 지원 기능, SMP 지원기능, 그리고 그 외 성능 강화 기능 등 확장성을 지원하는 다양한 기능들을 사용할 수 있다.

하지만, 확장성에 대한 깊이 있는 논의는 본 글에서 논외의 문제기 때문에 더 이상은 논하지 않기로 한다. 그러나 DB2가 사용자들의 성능 요구를 충족할 수 있는 확장성을 가지고 있으며, 그것이 고 가용성을 달성할 수 있는 주요 요인이라는 것은 기억해야 한다.

 

지속적으로 사용 가능한 데이터베이스 관리 소프트웨어를 가지고 있고, 그것으로 수천명의 사용자 요구를 충족할 수 있는 확장성 있는 데이터베이스를 유지하기 위해, 사용자들은 시스템 앞에 앉아 유지보수 작업을 진행하고 있다. 하지만 매우 드문 예외 상황이긴 하지만, 유지보수 작업 대부분을 온라인으로 수행하는 경우도 있다.

 

DB2는 백업, 복구, 온라인 인덱스 생성, defragmentation, space allocation, 자동 데이터 repartitioning과 같은 직업을 온라인으로 수행할 수 있는 기능을 제공한다. 이러한 주요 기능들을 사용함으로써 사용자들은 인터럽트 없이 데이터베이스를 유지보수할 수 있게 된다.

 

DB2 가용성에 있어 예외적인 사항들은 온라인 테이블 재구성 유틸리티(online table reorganization utility)에 좌우될 수도 있다. 현재 사용자들은 데이블 재구성 작업을 오프라인으로 처리하고 있다. 하지만, DB2 개발 작업에서 주목해야 할 부분은 로드 및 테이블 재구성 유틸리티들을 보다 가용성 있게 만드는 부분이다.

 

이제 가용성에 대한 새로운 국면으로 접어 들어보자.

시스템을 중단없이 지속적으로 운영하는 것만으로는 가용성에 대한 사용자 요구를 충족할 수 없다. 시스템이 가용성이 있다는 판단을 받기 위해서는 적어도 데이터베이스에 액세스하고자 하는 사용자들이 시스템을 사용하고 있을 동안, 시스템이 중지되거나 오류를 일으키거나 다운되는 일이 없어야 하며, 이에 대한 신속한 복구가 이루어져야 한다.

 

효율적인 백업 및 복구 - 온라인과 오프라인

 

가용성을 유지하기 위해선 신속한 데이터베이스 백업 및 복구가 실현되어야 한다. DB2 백업 유틸리티는 병렬 운영될 수 있으며, 다중 백업 및 복구(BU/R) 장치에 CPU 병렬 운영체제를 활용할 수 있다. 이것으로 백업 미디어의 데이터 처리량을 향상시킬 수 있다. DB2 백업 유틸리티가 활용할 수 있는 BU/R 소프트웨어들은 아래와 같다:

 

Tivoli Storage Manager(공식 명칭 : ADSM)

Veritas NetBackup

Legato Networker

IBM은 향후 더 많은 벤더들의 BU/R 소프트웨어를 지원할 계획이다.

이러한 애플리케이션들을 활용하면, 자동화된 네트웍 백업, 복구, 저장소 관리, 재해 복구 기능들을 추가할 수 있다.

백업 작업에 있어서 오프라인 작업 처리가 온라인 작업 처리보다 더 익수해져 있긴 하지만, DB2는 온라인 및 오프라인 백업 작업을 모두 지원한다.

 

DB2 백업 유틸리티는 매우 섬세한 기능들을 제공하는데, 예를 들면, 백업 작업을 데이터베이스 혹은 테이블 스페이스 수준으로 수행할 수 있다. DB2 아키텍처는 사용자들이 디스크 오류로 인해 사용할 수 없게 된 상당량의 데이터들을 현행 데이터로 만들거나(concurrency) 줄일 수 (reduction)있도록 하여 다중 컨테이너 및 디스크를 연결(span)할 수 있는 테이블 스페이스 곳곳에 데이터를 분산시킬 수 있다. 또한 DB2 UDB V7.2부터는 온라인 증분 백업(online incremental backup)을 수행할 수 있는 옵션이 추가될 것이다.

 

DB2 복구 유틸리티는 병렬로 작동되며, CPU 병렬 운영 체제를 다중 BU/R 애플리케이션이나 디바이스에 CPU 병렬 운영체제를 이용할 수 있다. 이 기능을 통해 복구 매체부터 디스크까지 보다 많은 데이터를 처리할 수 있는 능력을 부여한다. 대부분의 경우, 백업 만으로는 데이터베이스를 가용한 수준까지 복구하는데 충분치 않다.

 

일반적으로 사용자들은 데이터베이스 로그를 복구 작업에 부분적으로 활용한다. 데이터베이스 로그를 사용할 경우, 운영자들은 데이터베이스의 무결성이 수용 가능한 수준에 있던 시기를 파악할 수 있다. 데이터베이스와 테이블 스페이스 모두 지정된 시간에 복구될 수 있다. 이러한 기능은 애플리케이션 오류를 복구하는데 유용하다. DB2 UDB V.7도 데이터베이스를 재구동하는데 걸리는 시간에서 많은 향상을 이루었다. 이는 복구된 데이터베이스 및 테이블 스페이스의 복구 능력을 돕기 위한 노력이었다.

 

온라인 백업을 수행하거나 테이블 스페이스를 복구할 때 몇 가지 살펴보아야 할 고려 사항들이 있다. 보다 자세한 내용은 DB2 Administration Guide를 참조하라.

 

단일 포인트 오류 줄이기

 

소프트웨어 외부 요소로 인해 가용성이 영향받을 수 있다는 점을 시스템 가용성 문제 처리시 고려해야 할 것이다. 예를 들면, "부분 기록(partial writes)"으로 기인된 전원장치나 디스크 오류가 발생한 경우를 생각해 보자. 이런 경우, 디스크와 CPU 모두에 대해 끊임없는 전원 공급을 통해 적정 전원을 유지해야 한다.

 

한 디스크가 따른 디스크(별도 전원이 공급되는)로 미러링(mirroring)될 경우, 데이터 오류의 가능성은 줄어든다. 하지만, 미러링된 디스크와 원본 디스크가 다시 동기화 되지 못할 경우, 운영체제가 손상되지 않은 디스크의 데이터가 마스터 카피로 전환할 수 있을 지 보장할 수 없으므로, 데이터 노출(exposure)은 불가피하다.

 

저장 매체의 영향력 하에 있는 데이터베이스 로그는 어떨까?

듀얼 로그를 유지함으로써 로그 디스크 오류의 가능성으로부터 데이터를 보호할 수 있다. 이 때, DB2는 듀얼 로깅을 자동으로 시행하지 않는다. 오직 사용자가 직접 하드웨어나 운영체제를 통해 듀얼 로깅을 수행해야 한다. 향후 DB2는 곧 출시될 FixPack을 통해 듀얼 로깅을 지원할 것이다. 그렇게 되면 사용자들은 매체 오류로부터 데이터를 보호하기 위해 RAID 구성이나 IBM Shark(FlashCopy 포함)를 사용할 수 있을 것이다.

 

필자가 제시할 수 있는 최상의 팁(Tip)은 별도의 디스크에 로그와 데이터를 보관하라는 것이다. 첫째 로그를 잃더라도, 미러링된 두번재 로그를 사용하여 시스템을 가동시킬 수 있을 것이다. 데이터 디스크가 손상됐을 경우, 백업 및 데이터 디스크 로그를 이용하여 손상된 부분을 복구할 수 있다. 하지만, 망실된 로그의 백업이나 대체할 수 있는 로그를 가지고 있지 않을 경우엔 시스템 가용성을 유지하긴 어렵다. 이렇게 되면 데이터베이스가 다운되거나 사용할 수 없게 될 경우, 사용자들은 천문학적인 비용을 감당해 내야 할 것이다.

 

재해 복구를 위한 효과적인 메커니즘

 

재해가 발생할 때 어떤 조치를 취하는가? 지진이나 그 밖에 자연 재해가 발생할 때를 대비한 비즈니스 계획은 있는가? 만일 화재와 같이 인프라에 손상를 줄 수 있는 재해가 발생했을 경우, 이에 대비한 조치가 강구되어 있는가?

 

대부분의 기업들이 이와 같은 재해 상황을 복구할 수 있는 방책을 마련하고 있지 않으며, "그런 것은 일어날 리 없다"는 잘못된 개념하에서 시스템을 운영하고 유지보수하고 있다.

 

지난 99년 9월, Floyd라는 제4호 태풍이 미국 동부해안을 강타했다. 태풍 Floyd가 미친 피해는 그리 대단한 것이 못되었지만, 수천개의 기업과 가옥이 물에 잠겼으며, 몇 달동안 업무 및 생활이 마비되었다. 이 사건은 비즈니스를 마비시킬 수 있는, 예상치 못한 재해에 대한 한 가지 사례에 불과하다.

 

웹 사이트가 오류를 일으키는 데엔 여러 가지 원인이 있을 수 있다. 재해가 발생했을 경우, 일정 기간 사이트를 운영할 수 없게 된다. 사용자들은 이와 같은 재해를 정확하게 예상할 수는 없지만, 대비책을 강구하여 피해를 최소화 할 수는 있다. 다시 말하면, 예상치 못한 재해에 대해 완벽한 방비책을 세울 수는 없지만, 저장된 데이터를 가지고 다른 사이트에서 운영을 계속할 수는 있을 것이다. 이러한 유형의 가용성 문제에 대해 다양한 방법들이 강구될 수 있으며, 각각의 방법에는 저마다의 장점과 단점이 있을 수 있다.

 

제안할 수 있는 해결책으로는 규칙적인 백업과 보조 장치로 데이터를 이전시키는 것이다. 이 방법은 재해 방어에 있어서 최소 수준의 방법이다. 이것은 구현하는데엔 그다지 큰 비용은 들지 않지만, 데이터 손실의 가능성을 내재하고 있다. 이 방법은 손실된 데이터를 쉽게 대체할 수 있거나 혹은 데어터에 관한 다른 기록물이 존재할 경우엔 바람직하다 할 수 있다.

위에서 제시한 해결책을 확장한 방법으로, 백업 이미지뿐만 아니라 데이터베이스 로그를 별도의 매체에 저장하는 방법이 있다. DB2 기록 로그 사용자 종료(DB2 archival log user exit)를 가능케 함으로써, 파일이 닫히자마자 완료된 트랜잭션 정보를 담은 로그를 전달할 수 있다. 사용자 종료로 네트웍을 통해 원격 재해 복구 사이트로 파일을 복사하거나, 테이프와 같은 물리적 매체에 파일을 복사해 추후 사용할 수 있도록 한다. 데이터베이스 복구 시점은 백업 이미지의 그것보다 늦다. 물론 활성 로그 내에 있는 트랜잭션 정보들은 잃게 될 것이나, 정규 백업을 수행하는 것보다는 많은 데이터를 복구할 수 있을 것이다. 왜냐하면 데이터베이스를 복구한 다음 로그를 보낼 것이므로, 복구 시간은 더 길어지지만, 복구 작업 결과는 보다 완벽할 수 있다.

데이터베이스를 보호할 보다 나은 방법으로, 비동기식 데이터베이스 로그 디스크 미러링을 선택할 수 있다. 이 방법은 AIX환경에서 운영되는 HAGEO(High Availability Geographic Cluster ; 미러링 기능 제공)와 같은 몇몇 추가적인 소프트웨어 뿐만 아니라 네트웍화된 데어터를 전달해야 하기 때문에 위에서 소개한 두 가지 방법보다 비용은 많이 든다. 이 방법은 비록 몇몇 마지막으로 처리된 트랜잭션 데이터는 잃을 수 있지만, 재해 발생 시점과 가장 근접한 부분까지의 복구 데이터를 남길 수 있다. 이 방법이 가진 최대의 단점은 재구성(reorganization) 및 runstats와 같이 생산 시스템 상에서 수행된 운영 작업이 미러링 되지 않아 관련 작업을 재수행해야 한다는 것이다.

소개되어 있는 방법 중 가장 완벽한 데이터 복구 방법은 모든 데이터베이스 데이터와 로그 디스크를 동기적으로 미러링하는 것이다. 이러한 접근방법은 성능 및 네트웍 대역폭 충격(일반적으로 이러한 방법에서는 추가적인 IT 자원 및 네트웍 환경을 필요로 한다)에 있어 가장 많은 비용이 소요된다. 하지만 시스템 오류 시간까지의 데이터를 복구할 수 있으며, 제기된 트랜잭션을 잃지 않는다. 목표 데이터베이스에 수행된 모든 운영 작업들이 유지되고, 복구 기간이 가장 짧다. 사용자는 단지 로그 데이터를 끌어 올리기만 하면 되는 것이다. 이 방법의 단점은 소량의 변경 작업을 수행하거나, 고대역 네트웍을 갖추거나, 두 가지 요건을 모두 갖추고 있어야 한다. 또한 지리적으로 떨어져 있는 사이트로의 동기식 미러링 작업에서 오는 성능상의 충격이 발생하게 될 것이며, 고가의 소프트웨어, 하드웨어, 그리고 네트웍이 요구되어 소요 비용이 높다는 담점을 가지고 있다.

마지막 두 가지 방법에서는 재해 복구용 페일오버 소프트웨어와 함께 IBM의 중복 기능(DataPropagator Relational)을 사용한다. 만일 여기서 소개된 방법들 중 일부를 현업에 적용하고 있을 경우, 디스크 및 CPU와 같은 추가적인 시스템 자원이 필요하다는 것을 이해해야 하며, 이러한 작업이 원활히 수행될 수 있는 시스템 규모를 갖추어야 한다.

 

AIX 기반 HAGEO가 풍부한 클러스터 서비스를 제공하는 반면, Vinca(www.vinca.com)는 Windows NT 및 Windows 2000 환경의 원격 사이트로 미러링 할 수 있는 솔루션을 제공한다. HAGEO는 HACMP와 함께 지리적으로 떨어져 있는 사이트 2 곳에 미러링된 사이트를 제공한다.

 

시스템 운영 그 이상의 것

 

오늘날의 시장 환경에서는, 그것이 자연적으로 발생했던 어떤 목적을 수행하기 위해 시작했던 간에 가용성은 e-비즈니스 사이트가 갖추어야 할 최고의 성공 요건이다. 가용성은 데이터베이스가 가동한다는 것 이상의 의미를 가지고 있다. E-비즈니스 데이터베이스는 시스템 사용자들의 요구를 충족해야 하며, 최소한의 파일 분할만으로 시스템을 유지하여야 하며, 시스템 고장, 예기치 않은 재해 혹은 직원의 작업 오류로부터 신속히 복구되어야 한다.

 

DB2의 가용성은 어느 정도일까?

IBM은 지난 99년 2월 한층 강화된 IBM RS/6000 HA50과 HA-S70 클러스터 서버와, 비즈니스 핵심 애플리케이션 및 e-비즈니스 애플리케이션용 패키지 솔루션을 발표했다. 이와 함께 DB2가 99.998%의 가용성을 가졌으며, 연간 6분의 시스템 오류 시간을 보장한다는 연구결과가 함께 발표됐다(이번 연구는 2달간의 시스템 테스트를 통해 증명됐다. 테스팅 환경은 10GB에, 시스템 관리방식의 저장소 테이블 스페이스를 사용했고, SELECT, INSERT, UPDATE, 그리고 DELETE와 같은 OLTP 타입의 트랜잭션을 실행하는 동시사용자가 64명이었다).

 

DB2 UDB V.7의 고가용성

 

DB2 UDB V.7에는 DB2의 가용성을 강화할 장점들이 포함되어 있다:

 

증분 백업(Incremental backup)

스캔(scan) 최소화

병렬 복구 기능

필터링된 로그 복구 기능

백업 후 로그 급증(flushing)

 

DB2는 뛰어난 가용성으로 대규모 데이터를 쉽고 유연성 있게 관리할 수 있도록 도와준다. DB2를 사용함으로서 사용자는 하드웨어와 소프트웨어의 관점에서 데이터베이스를 구축하고 관리할 수 있도록 뛰어난 유연성을 제공한다. 이제 사용자는 자사에 가장 적합한 접근방법이 무엇인지를 고민해야 한다. DB2는 여러 가용성 컴포넌트들과 완벽하게 통합되며, 자사의 비즈니스 핵심 애플리케이션을 구축하고 유지보수할 수 있는 기반을 제공한다.

 

오늘날 치열한 기업 경쟁 상황에서 사용자들이 예측할 수 있는 것이라곤 예측하지 못했던 돌발상황이 발생하리라는 것이다. 사용자는 다음 단계 혹은 다음 상황에 어떤 사건이 발생할 지 알 수 없다. 그것이 무엇이건 간에 불확실한 미래에 대해 대비하는 수 외엔 이 상황을 이겨나갈 수 있는 길은 없다. 이른바 카오스가 눈 앞에 벌어져 있는 것이다. 하지만 그것에 겁 먹지 말고, 그 상황을 이용하고, 정의하고, 발전을 거듭하여 카오스 자체를 소유하라. 이것을 성취할 수 있다면, 기업의 문을 닫는 일은 없을 것이다.


[Top]
No.
제목
작성자
작성일
조회
438DB2 UDB 메커니즘
정재익
2002-10-17
13107
426IBM DB2 소개
정재익
2002-10-17
16795
227Clustering DB2 for Windows NT
정재익
2001-12-09
10757
214가용성 측면에서 살펴본 DB2 Software
정재익
2001-11-29
13595
213데이터베이스 가용성의 향상
정재익
2001-11-28
10970
154DB2 UDB 7.2의 새로운 기능 정리 [1]
이전건
2001-10-23
10250
149IBM DB2 7.2 vs Oracle 9i [1]
정재익
2001-10-18
9362
Valid XHTML 1.0!
All about the DATABASE... Copyleft 1999-2019 DSN, All rights reserved.
작업시간: 0.285초, 이곳 서비스는
	PostgreSQL v11.5로 자료를 관리합니다