안녕하세요? 질문에 감사드립니다. 휴먼에러에 대한 AI 기술적용을 차기 버전에서 고려중입니다.
DBMS 기능 관점으로 본다면 DBLInk 기술이 대표적일 것으로 보이며 Hadoop과는 별도 connector를 통한 방식일 것으로 보입니다. 그러한 기술을 이용하여 실시간 데이터를 조회/분석 할 수 있겠습니다.
이민주님, 안녕하세요, TSC의 경우 Azure, KT클라우드 환경에서도 제약 없이 설치가 가능합니다.
안녕하세요? 질문 감사드립니다. 질문하신 내용은 DBMS 제품의 기능적인 관점보다는 데이터 관리 등 DBMS를 사용하여 프로젝트를 수행하는 등의 SI 관점의 내용으로 파악됩니다. 벤더 입장에서 답변이 쉽지 않음을 양해 부탁드립니다.
티베로사에서는 블록체인에 대한 솔루션은 현재없으며, 티맥스의 관계사에서 솔루션에 대한 진행중입니다. 추가적인 연락처나 관심이 있으시면 컨텍해 드리도록 하겠습니다.
주기와 수명은 고객사 환경/설정 값에 따라 달라질 수 있습니다. 자세한 사항은 발표자에게 문의하기를 통해 질문을 남겨주시면 자세한 답변 드리겠습니다.
이형준님, 안녕하세요, 티맥스티베로입니다. 문의주신 사항 답변 드립니다^^ Snapshot standby로의 전환은 DB재부팅과 명시적인 DDL 명령어를 통해 이루어집니다(flashbask database 설정, snapshot redolog group 설정 등). 이후 DML의 변경은 스텐바이 노드에서 Redolog가 정상적으로 쌓여 동작하기 때문에 일반 DBMS와 크게 다름없이 운영하다 다시 Standby DB의 복구 모드로 전환이 되게 됩니다. 이때 Flashback database 기능이 활용되며 이때도 마찬가지로 DB 재부팅과 명시적인 DDL 실행으로 DB 모드가 변경되게 됩니다.
윤성원님, 안녕하세요, 티맥스티베로입니다. Snapshot Standby는 Flashbask Database 기능을 활용하여 복제 노드에 대한 동기화와 자유로운 DML을 동시에 처리할 수 있는 기능입니다. Snapshot 시점까지 복귀는 Flashback 기능을 활용하기 때문에 Flashback이 가지는 제약 사항을 그대로 따릅니다. 즉, Flashback log를 별도로 남기도록 세팅하는것이 기본적으로 필요하고 "손상된 데이터파일 복구가 불가" 등과 같은 몇몇 제약사항이 있습니다. 자세한 사항은 저희 Technet 사이트(https://technet.tmaxsoft.com/ko/front/main/main.do)의 Tibero 7 메뉴얼에서 확인 가능합니다.
TAC의 경우 각 노드가 대등하게 동작하는 방식이므로 VIP Fail-over등을 통해 SOF 를 방지하며 TSC의 경우, Observer 노드를 별도 서버로 설정하여 SOF를 방지하게 됩니다.
VIP Fail-over!! 몰랐는데...알려주셔서 감사합니다!
Multi-node Standby에서 Standby 노드 확장시에 기존 설정값 외에도 확장된 노드를 설정 하는 과정이 필요합니다.
병렬처리에 있어 티베로 인스턴스가 클러스터로 묶어 있건, Single로 동작하건 DBMS엔진단에서 데이터 정합성을 보장하게 되어 있습니다. 각종 Lock 메커니즘과 MVCC 등으로 이를 처리하게 됩니다. 핵심업무 전환사례는 티베로 TAC 적용사례가 1000건이 넘으며 대표적인 Oracle 전환 사례이며 그중 차세대 지방세 사업(3node TAC), 경찰청 기간계업무, 고려대의료원 P-HIS, 현대자동차 MES 등 대표적입니다.
남석호님, 안녕하세요, 티맥스티베로입니다. 1. DBMS 운영 중, 파라미터 변경 지원 - 운영 중 변경 가능한 동적 파라미터 지원 - 타 DB도 동적 파라미터 제공 2. online 테이블 컬럼 추가 - default value가 존재하지 않는 null 컬럼 추가시 매우 짧은 lock만을 획득함 - O사 DBMS도 유사함. - 기타 오픈소스의 경우 : add column 포함 일부 ddl 수행시 algorithm, lock 옵션 명시하여 lock 최소화 가능으로 설명 3. online table reorg - 블록 단편화로 인한 성능 저하 및 비효율적인 공간을 사용 중인 테이블에 대한 Online Reorg 수행 (DBMS_REDEFINTION 패키지 제공) - O사 DBMS도 tibero와 동일 패키지 지원 - 기타 오픈소스의 경우 : 그들만의 방식을 사용중인것으로 확인됨 (optimize command 지원 통한 짧은 lock만을 획득,autovacuum 지원/pg_reorg 유틸리티 제공 등) 이 정도로 정리할 수 있겠습니다^^
Async방식이 성능을 위한 방식이며, Cascade 방식 등이 또한 성능에 유리합니다.
안녕하세요. 티맥스티베로입니다. ProSync솔루션은 Oracle to Tibero, Tibero to Tibero의 환경만 지원합니다.
아 그렇군요...
질문감사드립니다. 현재 Tibero는 차기버전을 준비중이며 '24년경에 릴리즈될 것으로 보입니다. 본 제품은 클라우드 Native DBMS와 virtual DB를 표방하고 있습니다. 거기에 더하여 자율운영에 대한 기능이 고도화 되어 탑재될 것입니다. 현재 DB모니터링 관점에서는 티베로외 티맥스 OpenSQL 정도가 포함된 내용으로 로드맵을 잡고 진행중입니다.
김완수님, 안녕하세요, Actvie Clustering이라는 기술이 탄생하기 이전에 과도기적 형태의 Active-active 구성의 HA솔루션이 언급하신 문제가 존재했었습니다. 하지만 TAC의 경우 interconnect를 활용한 구성으로 두 노드간 연결이 되어있어 분리되어있는 instance에서 작업을 해도 하나의 서버에서 작업을 하는 Cache fusion이라는 기능이 지원됩니다. 이를 통해 정합성 오류를 방지합니다.
TSC에 관심을 가져 주셔서 감사합니다. TSC는 주로 공공사이트와 병원 등에서 사례를 가지고 있으며 최근 금융권에서 다양한 적용을 시도하고 있습니다. Tibero 7에 오면서 다양한 신기능과 안정성이 향상되었습니다.
ProSync는 이기종 DB에 대한 동기화를 지원하는 CDC 제품으로, 소스DB에 있는 오브젝트를 타겟 DB로 동기화하합니다. 때문에 두 DB를 관리하며 싱크를 맞추는 것보다 관리 복잡도가 내려갈 수 있습니다. 관리 복잡도는 그 외에도 고객사 인프라, 구성, 예산 등의 다양한 요소에 영향을 받을 수 있습니다. 자세한 사항은 질문하기로 문의 주시면 답변드리겟습니다.
이경석님, 안녕하세요, 티맥스티베로입니다. Tibero의 개발/관리 툴 TiberoStudio에서는 중복제거를 통한 압축기능을 따로 제공하고 있지 않습니다. 다만, Tibero에서 제공하는 압축 기능을 활용하시면 중복 내용은 압축되어 저장되어, 백업 스토리지 공간을 줄일 수 있습니다. 해당 기능 외에도 백업 시 RMGR의 Compress 옵션을 통해 백업 스토리지 용량을 줄일 수 있습니다.
안녕하세요. 티맥스티베로입니다. 비용 측면에서 신규 구축 비용 및 유지보수 비용이 상당히 저렴하기 때문에 Tibero가 상당한 강점을 가집니다. 또한 프로젝트 시작부터 오픈 이후 안정화까지 밀착으로 기술지원이 이루어진다는 점에 강점이 있습니다.
고객사 환경, App 구현 방식, 예산 등의 다양한 고려 요소가 있기에 무엇이 유리하다고는 볼 수 없습니다. 일례로 물리적으로 동일한 장소에 잇는 Stnadby는 물리적으로 멀리 떨어진 Standby 노드보다 빠른 failover가 가능할 수 있습니다. 반대로 같은 공간의 재난이 발생할 경우 dB 전체가 장애가 일어나는 등의 위험요소가 있습니다. 따라서 고객사 환경/App 연동/예산 등의 고려사항을 통해 구성 방식을 결정하시는 것이 좋습니다. 자세한 사항은 발표자에게 문의하기를 통해 질문주시면 감사하겠습니다.