아직 답변이 없습니다
안녕하세요, 인텔코리아입니다. 인텔 제온 스케일러블 프로세서를 적용한 고객 사례를 참고하실 수 있는 링크 첨부 드립니다. https://www.intel.co.kr/content/www/kr/ko/industries/overview.html
안녕하세요, 인텔코리아입니다. 현재 제온 스케일러블 프로세서에서는 QAT 기반의 다양한 암호화 알고리즘을 지원하고 있습니다. 관련된 자료는 아래 링크 참조 부탁드립니다. https://www.intel.co.kr/content/www/kr/ko/architecture-and-technology/intel-quick-assist-technology-overview.html
안녕하세요. 티맥스티베로입니다. 자사 제품 중 어플라이언스 제품으로 'ZetaData'를 제공하고 있습니다.
박완주님, 안녕하세요, 티맥스티베로입니다. 아무래도 DBMS 작업을 수행함에 있어도 고려할 것이 많은것이 시스템 운영인듯합니다. 정말 민감한 시스템이라면 영향도를 사전에 파악하여 패치나 업그레이드를 적용하는 방안이 있습니다. 운영 중의 트랜잭션 로그를 별도로 남겨 변경된 DB에 재생하여 사전 영향도를 분석하는 개념입니다. 단, 별도 서버 구성, 데이터의 복제와 구성 등 많은 비용과 시간적인 것이 고려되어야만 하는 단점이 있습니다.
윤성원님, 안녕하세요, 티맥스티베로입니다. 1. Tibero DBMS관점에서는 DBMS를 OLTP로 할것이냐, OLAP으로 할 것이냐에 따라 DB 설정을 달리 구성할 수 있을듯합니다. 또한, 티베로는 분석을 위한 다양한 함수를 지원하기에 정보계로 사용하는 경우도 많습니다. 2. ExaData와의 비교측면에서는 Tibero에도 ZetaData라는 DB Appliance 제품이 있습니다. Oracle에 Tibero가 대응되듯 Exa에 Zeta가 똑같이 대응되는 구조라고 생가하시면 됩니다. X86서버의 사용, flashcache 지원, infiniband 스위치 활용 등 대용량 /고성능 처리를 지원합니다. 제조, 병원, 공공등에 다수 사례를 보유하고 있습니다.
클라우드 환경에 맞는 스냅샷 기능도 DBMS 상품을 론칭시 테스트를 거쳐 지원하고 있습니다. 새로운 환경에 대한 요구는 3rd party 연동관점에서 신속하게 지원하고 있습니다.
안녕하세요. 티맥스티베로입니다. Oracle에서 Tibero로 전환한 사례는 공공, 금융 등 대형시스템을 비롯하여 수많은 성공적인 전환 레퍼런스를 보유하고 있습니다. 관련하여 자세한 자료는 영상 하단의 발표자 문의하기를 통해 남겨주시면 답변드리도록 하겠습니다.
안녕하세요, 전은상님, Tibero는 높은 Oracle 호환성을 바탕으로 '22년 7월 기준 약 1,100여건의 오라클 전환 사례를 보유하고 있습니다.
안녕하세요? 질문에 감사드립니다. 자율 운영 측면의 기능은 티베로 차기 버전에서 준비중입니다.
안녕하세요. 티맥스티베로입니다. Tibero는 SE(Standard Edition), EE(Enterprise Edition) 및 병렬처리, TAC(Tibero Active Cluster)등의 옵션으로 세분화하여 사용하시고자 하는 DB에 적합한 선택이 가능합니다.
이민주님, 안녕하세요, 티맥스티베로입니다. 무결성 체크가 정확히 어떤 기능을 말씀하신건지는 의미를 알 수 없지만 만약 begin backup 수행 시 redo log의 정합성 체크가 되었다 하더도 OS나 HW 등의 문제로 복구 시점에 복구에 필요한 파일이 손상되었다면 경우에 따라 완전복구(Complete Recovery)는 어렵습니다. Case별 복구 절차는 아래와 같습니다. 1. Inactive redo 로그 그룹의 일부 멤버 손상 Inactive redo 로그 그룹의 멤버 중 하나가 손상된 경우 티베로는 정상 운영되며, 명령어로 손상된 멤버를 삭제하고 다시 추가하면 됩니다. 2. Current redo 로그 그룹의 모든 맴버 손상 후 정상 종료 Current redo 로그 그룹에 속한 redo 정보가 데이터베이스에 반영된 시점에 Current redo 로그 그룹에 속한 모든 멤버에 손상(OS File 삭제 등)이 발생하면 Current redo 로그 그룹에 있는 redo 내용은 복구할 필요가 없습니다. 티베로를 RESETLOG 모드로 기동하면 Redo 로그 그룹이 초기화되어 새로 생성됩니다. 3. Current redo 로그 그룹의 모든 맴버 손상 후 비정상 종료(Incomplete Recovery) Current redo 로그 그룹에 속한 redo 정보가 데이터베이스에 반영되지 못한 시점에 Current redo 로그 그룹에 속한 모든 멤버에 손상(OS File 삭제 등)이 발생하면, Current redo 로그 그룹을 사용하기 직전 시점으로 복구할 수 밖에 없습니다. Incomplete Recovery 수행. 4. System 테이블스페이스의 파일 손상(Complete Recovery) System 테이블스페이스의 데이터 파일이 손상된 경우, 티베로 종료 후 백업본을 복원하고 Archive log와 Redo 로그 파일을 적용하여 장애 직전 시점으로 Complete Recovery 합니다.
안녕하세요. 인텔코리아입니다. 제온 프로세서를 사용하여 혁신을 가속화하시려는 경우, 실제로 사용하시는 워크로드가 어떤 것인지 먼저 확인하시고 그에 맞는 프로세서를 선택할 수 있도록 고려해야 합니다.
양재영님, 안녕하세요, 티맥스티베로입니다. 1.1. SuperITAM 방향 - IaaS, PaaS, SaaS 단일 Cloud Full Stack 통합 관리 - Multi/Hybrid Cloud 통합 관리 - Client~Server 통합 관리 1.2. SuperITAM 로드맵 : HostOS Master, GuestOS Master, Platform OS (Container) Master, Middleware Master 영역 7월 / DBM, PCM 등 로드맵 일정에 따라 통합 로드맵 일정 수립 예정 (About '23 4Q 목표) 2. DB 전환 시 수작업 최소화 등 : GUI 기반의 T-UP 전환 툴은 전환호환성 분석, 데이터 이관, 이관 후 무결성 검증을 수행합니다. 툴을 사용하기 때문에 작업의 효율성이 높아집니다. 단, Oracle DBMS를 제외한 DBMS의 경우에는 많은 제약사항이 따릅니다. 즉, 수작업을 통해 대부분 진행된다고 보시면 됩니다.
아직 답변이 없습니다
안녕하세요. 티맥스티베로입니다. 티베로는 국산 DBMS로서 외산 DBMS보다 비용적인 측면에서 강점을 가집니다. 신규 구축 비용 및 유지보수 비용이 외산 DBMS보다 상당히 저렴하다고 보시면 됩니다. 또한 프로젝트 시작부터 오픈 이후 안정화까지 신속한 기술지원을 지원한다는 장점을 가집니다.
강덕진님, 안녕하세요, 티맥스티베로입니다. 이론적으로는 문제가 없을듯합니다. 다만, 저희가 실제 구성하거나 테스트한 사례는 없습니다. 가령, TSC의 Observer를 어디에다 둘 것인가? 네트워크 성능은 이상없는지? 자동 Fail-Over시 플랫폼의 제약은 없는지 등 고려사항이 있어 보입니다.
이민수님, 안녕하세요, 티맥스티베로입니다. 티베로를 도입하여 운영중이시라면 새로운 제품으로의 업그레이드, 또는 기능 적용을 통해 안정성을 보장 받으실 수 있을듯합니다. 티베로를 최초 도입하시거나 신규 프로젝트에 도입을 고려중이시라면 업무시스템의 성격, 중요도 등에 따라 적절한 아키텍처를 구성하여 사용하시면 될듯합니다. 이러한 부분은 저희 티베로에서 지원드릴 수 있습니다.
최성태님, 안녕하세요, 티맥스티베로입니다. 대용량 데이터를 분석하는 관점은 여러 가지가 있을듯합니다. DBMS, DB Appliance의 도입, 고속 하드웨어, 네트워크의 구성, 우수한 빅데이터 솔루션의 도입, 분석 데이터에 대한 모델링 등 매우 다양한 것으로 사료됩니다. 저희 티베로 입장에서 말씀드릴 수 있는 부분은 얼마나 대용량의 데이터를 DBMS에 저장하고 안정적으로 빠르게 관리하고 응답할 것이냐의 문제로 보여집니다. 이런 것을 제품 기능으로 지원하는 부분은 병렬 처리, 파티셔닝 처리 등이 대표적이라 판단되며 티베로는 여타 DBMS대비 경쟁력 있는 기능과 성능을 제공합니다.
질문에 감사드립니다. 질문하신 내용은 주로 애플리케이션 구축 관점에서의 고려 사항인듯합니다. DBMS 아무래도 얼마나 정확하고 빠르게 데이터 처리 요구에 대응하냐가 DBMS에서 측면에서 중요한 고려사항인듯합니다. 제품선정시 BMT나 PoC 등을 통한 업무 특성에 맞는 DBMS선정이 필요할듯합니다.
패치 등의 무중단 서비스 지원은 클러스터 노드 환경에서 가능하며 안전성에 대한 담보는 패치셋을 구성하고 배포시 패치들의 연관성과 상호영향도를 품질 테스트 등을 거쳐 처리하고 있어 안심하고 사용가능하십니다.
패치시 TSC의 구성일 경우 Standby 노드에 대해 패치를 하고, 이후 Failover를 통해 Active 노드를 Standby노드로 바꿉니다. 이어서 Standby로 바뀐노드에 대한 패치를 진행합니다. 해당 방식을 Rolling Patch라 하며, 티베로에서도 해당 방식을 지원합니다. 또한 동일 스펙의 노드가 App과 연동되는 방식이기에 성능은 동일합니다.