이민수님, 안녕하세요, 티맥스티베로입니다. 인텔의 4세대 프로세서와 티베로 DBMS를 선택하시고 찾아주시면 최선을 다해 지원드리겠습니다^^
안녕하세요. 티맥스티베로입니다. 현재 Tibero는 가장 대중적으로 사용되는 400여개의 3rd Party 솔루션(CDC, ETL, EAI...)들과 연동 인증이 되어 있으며 이외의 솔루션들도 표준 JDBC, ODBC 인터페이스를 통하여 연동을 지원합니다.
쿠버네티스 환경과 백업은 크게 관계가 없는 영역으로 보입니다. 가능한 영역으로 판단됩니다.
말씀하신 것처럼, CDC나 TSC의 경우, TAC도 마찬가지로 빠른 응답속도와 대용량 처리를 위해서는 티베로자체적인 성능외 네트워크의 Latency와 서버 성능이 전제가 되어야 합니다. 네트워크와 서버측 영역은 티베로 외적인 영역으로 구분됩니다.
현재 PostgreSQL만 지원합니다. '24년에는 MariaDB를 지원할 계획입니다. 아무래도 장점은 상용벤더에서 안정적으로 오픈소스를 공급하고 기술지원한다는데 있다고 판단됩니다.
네 정확하십니다. Observer와 각 DB 노드가 지속적으로 헬스 체크를 하게 되며 이를 observer노드가 장애 발생시 인지하게 되고 자동 페일오버를 수행하는 구조입니다.
안녕하세요. 티맥스티베로입니다. Flashback의 경우 Flashback Log File 이 따로 존재하고 있습니다. Flashback 복구는 Flashback Log, Redo Log를 통하여 복구하고 있으며 Redo Log에 문제 발생시 Flashback Log가 보관된 Marker 상태까지의 복구만 지원합니다.
아 별도의 log를 사용하는 군요...답변 감사합니다. 그럼 redo log와 flash log는 상호 보완관계는 아닌가보군요.. 혹시 어떤 관계인가요?
안녕하세요. 티맥스티베로입니다. 상호보완 보단 따로 별개의 로그파일로 파악해주시면 될 것 같습니다.
티베로 3rd Party 인증센터를 통해 업체 컨텍부터 연동 테스트 등을 체계적으로 지원하며 기능 적용 필요시 연구소를 통한 빠르게 지원하고 있습니다.
안녕하세요? 질문에 감사드립니다. 휴먼에러에 대한 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 방식 등이 또한 성능에 유리합니다.