김명환님, 안녕하세요, 티맥스티베로입니다. DBMS는 어떠한 상황에서도 커밋된 데이터에 대하여 데이터 유실이 발생하지 않게 하기 위한 고도의 기술들을 적용하여 제품화 하고 있습니다. 본 세션에서도 말씀드렸던 백업/복구, Flashback Database 등의 기술이 해당된다고 보시면 됩니다. 롤백, redo log, archivelog, flashback log 등을 기반으로 standby, DR 구성 등을 통해 어떤 순간에도 데이터 정합성을 유지합니다.
특정 시점의 DB 복구시에는 현재 App 과 연동하기 위해서도 잠시의 중단시간이 필요합니다.
문주웅님, 안녕하세요, 티맥스티베로입니다. 인텔의 4세대 프로세서와 티베로 DBMS을 선택하시고 찾아주시면 최선을 다해 지원드리겠습니다^^
운영중 파라미터 변경은 Standard edition에서도 지원하고 있습니다.
질문감사드립니다. 너무 포괄적인 질문이라 적절한 답변을 드리기가 쉽지 않은점 양해 부탁드립니다. DBMS관점에서는 프로젝트마다 차이는 있겠지만 DBMS가 기존환경과 다르게 변경되는 프로젝트의 경우, DBMS의 안정성이나 성능에 대한 것을 어떻게 확보는가에 대한 계획과 준비/ 테스트 과정을 많이는 고려하는 것으로 보입니다.
이민수님, 안녕하세요, 티맥스티베로입니다. 인텔의 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 메뉴얼에서 확인 가능합니다.