저희 내부의 knowlege base 있는 경우는 크게 이슈가 없으나, 신규 패턴 발생 시 변환 로직 및 데이터 검증을 위한 케이스 수립 등이 필요하므로 추가적인 시간이 필요할 수 있습니다.
정형 데이터의 경우 각 DBMS 타입 간 호환성을 고려하면 크게 무리가 없으나, 비 정형의 경우 DBMS 의 지원 여부에 따라 저장 방식이 다를 수 있으므로 AP 관점도 변환 여부도 고려가 필요합니다.
동일 DBMS 에서도 암호화 솔루션이 변경이 되는 경우에도 마이그레이션 수행 시 복호화 후 암호화를 진행하여야 합니다.
초기 시작 단계에서는 DB 내의 오브젝트 수, 데이터 용량, AP 유형, 연계 시스템, 솔루션에 대한 정리가 필요하며, 추가적으로 검증을 위한 주요 SQL 등을 제공해 주시면... 좀더 빠르게 진행할 수 있을듯 합니다.
기본적으로 이기종 간에 변환은 각 DBMS 가 제공하는 호환모드를 기본으로 사용합니다. 이후 저희가 가진 knowlege base를 가지고 변환 상에 이슈가 있는 패턴 매칭응 대상으로 검증 대상을 선별하며 asis vs tobe 간에 결과를 비교하게 됩니다
기존 마이그레이션 사례가 있어서,,, 적은 마음 고생으로 한방에 전환하실 수 있습니다. ^^
LUW Db2로 전환한다면 데이터 전환은 필요하나, 데이터 전환 절차는 같은 IBM 제품이기 때문에 심플하게 전환할 수 있습니다.
Federation 기능을 통해 가능하며, 연결 가능한 데이터 소스는 아래 URL에서 확인 가능합니다. https://www.ibm.com/support/pages/node/957245
백업 데이터에 대한 형태의 구현이라 부분이 어떤 부분을 말씀하시는 판단이 안되나,,, 백업 수행 시 encrypt 옵션을 사용하여 백업 이미지에 대한 압축이 가능합니다.
현재 설명하고 있는 KB은행이 가장 큰 사례입니다.
flashback 기능은 없으나, 유사한 형태를 기능적으로 구현할 수는 있습니다. 백업 본에서 과거 특정 시점은 데이터 추출은 여분의 시스템이 있다면 백업 이미지와 아카이브 로그를 이용해서 point in time recovery 형태로 데이터 추출이 가능합니다.
BLU는 컬럼 테이블 형태로 구성하며, 실제 데이터는 압축된 상태로 저장이 되며, 컬럼 테이블이기 때문에 압축률 또한 매우 높습니다 데이터 처리는 압축된 상태로 수행이 되며, 필요한 전체 데이터가 항시 메모리에 올라가 있는 것은 아니며, 압축된 데이터를 zone map 형태인 synopsys table 을 통해 active data 만 적재되어 처리되게 됩니다.
기존 DBMS가 어떤 것을 사용하는 부분에 따라 다르겠지만,,, 일반적인 표준 SQL을 사용하는 경우 변환에는 크게 어려움이 없으며, 특정 DB에 종속적인 기능을 사용하는 경우 (오라클 예를 들면, 오라클 호환 모드 사용 시) 높은 호환성을 제공하고 있습니다.
압축사전 정보만 메타 정보 형태로 저장하므로 해당 오버헤드는 미미하며, 압축으로 인해 스토리지 감소량이 얍축률에 따라 차이가 있지만 스토리지 사용량 감소가 매우 높습니다.
federation 기능을 통해 이기종 접속이 가능하며, 접속에 사용되는 계정의 암호 암호화 되어 서버에 저정이 되며,,, 전송되는 데이터는 SSL 통해 가능합니다. https://www.ibm.com/docs/en/db2/11.5?topic=federation-security-federated-servers
pureScale 통해 active & active 구성이 가능합니다.