기존 DB 서버에서 신규 DB 서버로 특정 테이블스페이스를 이관하고, 두 서버 간 이중화 및 동기화를 구성

티베로 6 환경 구성에 대한 고려 사항을 단계별로 정리해 드립니다. 기존 DB 서버에서 신규 DB 서버로 특정 테이블스페이스를 이관하고, 두 서버 간 이중화 및 동기화를 구성하는 시나리오에 맞춰 주요 검토 항목들을 설명드리겠습니다.

1단계 & 2단계: 신규 DB 서버 구축 (동일 네트워크 존, Oracle Solaris OS, Tibero 6 설치)

• 서버 사양: 기존 DB 서버와 최소 동등하거나 더 나은 사양 (CPU, Memory, Disk I/O)을 권장합니다. 특히 이중화 구성 시 부하를 감당할 수 있어야 합니다.
• OS 호환성 및 설정:
  • OS 버전: 설치할 티베로 6 버전과 호환되는 Oracle Solaris 버전을 사용해야 합니다. (Tibero 설치 가이드 확인 필요)
  • 패키지 및 커널 파라미터: Tibero 설치 및 운영에 필요한 OS 패키지 설치 및 커널 파라미터 최적화가 필요합니다. (Tibero 설치 가이드 참조)
  • OS 사용자 및 그룹: Tibero 소프트웨어 소유자 및 그룹 (예: tibero) 생성 및 권한 설정이 필요하며, 가능하면 기존 서버와 일관성을 유지하는 것이 좋습니다.
  • Endianness 확인: 기존 서버의 OS와 신규 Solaris 서버의 Endian 방식이 다를 수 있습니다. 이는 데이터 파일의 물리적 이관(예: Transportable Tablespace) 시 호환성 문제를 일으킬 수 있으므로 확인이 필요합니다. (Solaris는 보통 Big-Endian, Linux x86 등은 Little-Endian)
• Tibero 설치:
  • 기존 서버와 동일한 Tibero 6 버전 및 패치 레벨을 설치하는 것을 강력히 권장합니다. 버전 불일치는 이중화 구성 및 운영 시 예기치 않은 문제를 발생시킬 수 있습니다.
  • Tibero 환경 변수 ($TB_HOME, $TB_SID 등) 설정을 정확하게 수행합니다.

3단계: B 테이블스페이스 이관 (기존 Tibero -> 신규 Tibero on Solaris)

• 이관 방법 선택:
  • Tibero Data Pump (tbExport/tbImport or tbLoader):
    • 가장 일반적인 논리적 이관 방법입니다. OS나 Endian 방식에 상관없이 이관 가능합니다.
    • B 테이블스페이스에 속한 객체(테이블, 인덱스, 등)를 export 받고, 신규 서버에서 import 합니다.
    • 데이터 양이 많을 경우 시간이 오래 걸릴 수 있습니다.
    • 이관 전후 객체 수, 데이터 정합성 검증이 필수입니다.
  • Transportable Tablespace (TTS):
    • 데이터 파일 자체를 복사하여 이관하므로 대용량 데이터 이관 시 빠릅니다.
    • 중요: 기존 서버 OS와 신규 Solaris 간 Endian 방식이 다르다면, Tibero 6에서 Cross-Platform TTS 기능을 지원하는지, 지원한다면 변환(convert) 과정이 필요한지 반드시 Tibero 매뉴얼을 통해 확인해야 합니다. Endian이 다를 경우 단순 파일 복사로는 이관되지 않습니다. Tibero의 특정 버전 및 기능 지원 여부 확인이 매우 중요합니다.
    • 메타데이터(객체 정의)는 별도로 export/import 해야 할 수 있습니다.
• 사전 준비:
  • B 테이블스페이스에 의존하는 객체(다른 테이블스페이스의 FK 제약조건, 프로시저, 함수 등) 확인 및 처리 방안 마련.
  • 이관 대상 객체 목록 및 데이터 용량 파악.
  • 이관 작업 중 서비스 영향 최소화를 위한 작업 계획 및 다운타임 확보.
• 이관 후 검증:
  • 객체 상태(VALID/INVALID) 확인 및 INVALID 객체 컴파일.
  • 데이터 정합성 검증 (로우 카운트, 샘플 데이터 비교 등).
  • 인덱스, 제약조건 등 재확인.

4단계: 이중화 및 동기화 구성 (기존 <-> 신규 서버)

• 이중화 방식 선택:
  • Tibero Standby (Active/Passive):
    • 가장 일반적인 재해 복구 및 고가용성 구성입니다. Primary DB의 변경 사항(Redo Log)을 Standby DB로 전송하여 동기화합니다.
    • 일반적으로 전체 데이터베이스를 복제하여 구성합니다. 특정 테이블스페이스만 분리하여 Standby를 구성하는 것은 표준 방식이 아니며, 구현이 복잡하거나 불가능할 수 있습니다. B 테이블스페이스 이관 후, 전체 DB를 기준으로 Standby를 구성하는 방향을 고려해야 합니다.
    • Active Standby의 경우 읽기 작업 부하 분산이 가능합니다.
  • TAC (Tibero Active Cluster):
    • Oracle RAC와 유사한 Active-Active 클러스터 구성입니다.
    • 여러 노드가 동일한 데이터 파일에 접근하므로 공유 스토리지(SAN, NAS 등)가 필수입니다.
    • 이 구성은 특정 테이블스페이스를 다른 서버로 '이관'하는 개념과는 다릅니다. 모든 노드가 모든 데이터(a, b 테이블스페이스 포함)를 공유합니다.
    • 만약 TAC를 구성하려면, 신규 서버 구축 시 공유 스토리지를 준비하고, 기존 서버의 데이터 파일 전체를 공유 스토리지로 옮긴 후, 두 노드가 이 공유 스토리지를 사용하도록 구성해야 합니다.
  • 요청 사항의 재해석: 만약 'b 테이블스페이스' 관련 업무를 신규 서버로 완전히 분리하고, 두 DB 간의 데이터 참조가 필요하다면 DB Link 등을 고려할 수 있으나, 이는 요청하신 '이중화 및 동기화'와는 다른 아키텍처입니다. 원하시는 최종 목표(고가용성, 부하 분산, 재해 복구 등)에 맞춰 TAC 또는 Standby 구성을 적용하는 것이 일반적입니다.
• 이중화 구성 시 고려 사항 (Standby 기준):
  • 네트워크: Primary-Standby 간 안정적인 로그 전송을 위한 충분한 대역폭 확보 및 낮은 지연 시간. 방화벽 설정 (Listener 포트, Log 전송 포트 등).
  • Tibero 파라미터: 로그 아카이브 모드 설정, Standby 관련 파라미터 설정 (LOG_ARCHIVE_DEST_n, CM 관련 설정 등).
  • 초기 데이터 동기화: Standby 구성 시점의 데이터 일치를 위해 Primary DB 백업본을 Standby 서버로 복원하는 과정 필요. (B 테이블스페이스만 이관된 상태에서 Standby 구성은 어려움)
  • Failover/Switchover: 역할 전환(Primary <-> Standby) 절차 및 스크립트 준비, 충분한 테스트 수행.

5단계: 전체 환경 구성 시 고려 사항 요약

• 네트워크 구성:
  • DB 서버 간 통신 (Listener, 이중화 로그 전송, TAC Interconnect 등)을 위한 네트워크 대역폭 및 안정성 확보.
  • 방화벽 정책 검토 및 필요한 포트 오픈 (Listener 기본 포트 8629, 이중화 구성 포트 등).
  • 동일 네트워크 존이라도 서버 간 Latency 확인. TAC 구성 시 Private Interconnect 네트워크 분리 권장.
  • VIP (Virtual IP) 또는 SCAN (Single Client Access Name - TAC 경우) 설정 고려 (Client 접속 투명성).
• DB 서버 간 구성:
  • tbdsn.tba 파일 설정 (Client 접속 및 DB Link 용).
  • 이중화 설정 파라미터 동기화 및 관리.
  • DB Link 필요 시 생성 및 권한 설정 (만약 Standby/TAC가 아닌 분산 환경이라면).
• 서버 구성:
  • OS: 버전 호환성, 커널 파라미터, 사용자/그룹 일관성, Endian 차이 고려.
  • Storage: 충분한 디스크 공간 확보 (데이터 증가분, 아카이브 로그, 백업 등). I/O 성능 중요. TAC 구성 시 고성능 공유 스토리지 필수.
  • 하드웨어: CPU, 메모리 등 자원 용량 산정 (이중화 환경 부하 고려).
• 속도 점검 (성능):
  • 이관 전: 기존 시스템 성능 지표(주요 SQL 수행 시간, TPS 등) 측정 (Baseline).
  • 이관/이중화 후: 동일 조건에서 성능 비교 측정. 특히 B 테이블스페이스 관련 작업 성능 및 이중화 동기화(Log Apply 등) 성능 확인.
  • 네트워크 Latency가 DB 성능에 미치는 영향 분석.
  • 부하 테스트를 통한 안정성 및 성능 한계점 확인.
• 기존 응용 S/W 변경:
  • DB 접속 정보: 신규 서버 접속 또는 이중화 구성에 따른 VIP/SCAN 주소 변경 필요. (tnsnames.ora 또는 이와 유사한 설정 파일, Connection Pool 설정 등).
  • 로직 변경: 만약 B 테이블스페이스 관련 데이터 접근 방식이 변경되거나, Standby 구성 후 읽기/쓰기 분리가 필요하다면 애플리케이션 로직 수정이 필요할 수 있음.
  • 테스트: 변경된 환경에서 모든 응용 S/W 기능 및 성능 테스트 필수.
• 추가 고려 사항:
  • 백업 및 복구 전략: 변경된 아키텍처(이중화 구성)에 맞는 백업 및 복구 전략 수립 및 테스트. (tbrmgr 활용)
  • 라이선스: 신규 서버 및 이중화 기능(Standby, TAC) 사용에 대한 Tibero 라이선스 정책 확인 및 확보.
  • 보안: 신규 서버 보안 설정 강화, DB 접근 통제 정책 재검토.
  • 다운타임: 테이블스페이스 이관 및 이중화 구성 작업 시 발생하는 서비스 다운타임 최소화 방안 마련 및 사전 공지.

결론:

요청하신 내용은 단순히 테이블스페이스를 옮기는 것을 넘어, OS 변경 및 DB 이중화 구성을 포함하는 복잡한 작업입니다. 특히, 특정 테이블스페이스만 이관 후 전체 DB를 기준으로 동작하는 표준적인 이중화(Standby/TAC)를 구성하는 부분은 아키텍처적으로 재검토가 필요할 수 있습니다.

가장 중요한 것은 Tibero 6의 특정 버전 매뉴얼을 참조하여 OS 호환성, Cross-platform TTS 지원 여부, Standby/TAC 구성 절차 및 제약 사항을 명확히 확인하는 것입니다. 또한, 실제 적용 전에 충분한 테스트 환경을 구축하여 검증하는 것이 필수적입니다.

성공적인 구축을 위해서는 TmaxTibero 기술 지원팀과의 협의나 전문 엔지니어의 도움을 받는 것을 권장합니다.

출처: Gemini