환경 구성
일부 단계를 자동화하는 데 스크립트를 사용할 수 있습니다. 이 스크립트는 전체 설정을 자동화하지 않으므로 태스크를 완료해야 하며 참조 시 스크립트를 사용할 수 있습니다.
이 문서에 참조된 스크립트를 다운로드하려면 링크를 보려면 코드 다운로드로 이동하십시오.
기본 데이터 센터에서 WebLogic 데이터 소스 준비
TNS 별칭은 기본 및 보조에서 동일한 이름이므로 데이터 소스는 동일한 DB 연결 문자열을 사용합니다. standby로 복사되지 않은 tnsnames.ora 파일로 분석되므로 각 사이트에서 서로 다른 tnsnames.ora 컨텐트를 가질 수 있습니다. 사이트 간에 복제되지 않는 파일 시스템에서 WebLogic 도메인 구성과 별도로 배치할 수 있습니다. 또는 구성의 일부인 경우 도메인 구성 아래의 폴더에 저장할 수도 있습니다. 이 경우 도메인 구성을 기본에서 대기로 복사할 때 해당 폴더를 제외해야 합니다. 각 사이트는 로컬 데이터베이스만 가리키는 각 사이트에 적합한 연결 문자열로 TNS 별칭을 분석합니다. 예를 들면 다음과 같습니다.
Connect string in data sources in primary site:
jdbc:oracle:thin:@mypdbservice
The tnsnames.ora file in primary contains:
MYPDBSERVICE =
(DESCRIPTION=
(ADDRESS_LIST=
(LOAD_BALANCE=ON)
(ADDRESS=(PROTOCOL=TCP)(HOST=prmy-scan)(PORT=1521)))
(CONNECT_DATA=(SERVICE_NAME=mypdbservice.example.com))
)
Connect string in data sources in secondary site:
jdbc:oracle:thin:@mypdbservice
The tnsnames.ora file in secondary:
MYPDBSERVICE =
(DESCRIPTION=
(ADDRESS_LIST=
(LOAD_BALANCE=ON)
(ADDRESS=(PROTOCOL=TCP)(HOST=stby-scan)(PORT=1521)))
(CONNECT_DATA=(SERVICE_NAME=mypdbservice.example.com))
)다음은 TNS 별칭을 사용할 경우의 장점입니다.
- 동일한 DB 접속 문자열이 WebLogic 도메인
config에서 사용되므로config를 기본에서 대기로 복제한 후 WebLogic 구성을 변경할 필요가 없습니다. - 각 사이트가 로컬 데이터베이스만 가리키므로 중간 계층에서 원격 데이터베이스로의 교차 연결 위험이 없습니다.
기본 WebLogic 서버 시스템에서 이 접근 방식을 아직 사용하고 있지 않은 경우 다음 단계를 수행하여 데이터 소스에서 TNS 별칭을 사용합니다.
네트워크 구성
Oracle Data Guard 구성
데이터베이스 버전 및 패치 레벨 정보
온-프레미스 데이터베이스의 Oracle 홈과 OCI의 대기 데이터베이스는 버전이 동일하고 패치 레벨이 동일해야 합니다. 다음과 같은 방법으로 이 작업을 수행할 수 있습니다.
- OCI에서 DB 시스템 프로비전 중 데이터베이스 소프트웨어 이미지를 선택하는 경우 모든 버전 표시를 선택하고 온-프레미스 데이터베이스와 동일한 데이터베이스 버전 및 패치 세트 레벨을 선택합니다.
- 소스 데이터베이스의 Oracle 홈 버전을 OCI에서 프로비전에 더 이상 사용할 수 없는 경우 소스 환경을 클라우드 환경의 데이터베이스 홈과 동일한 데이터베이스 패치 레벨로 패치해야 합니다.
다음 시나리오는 참조를 위한 실제 예입니다. 온-프레미스 DB 홈은 19.6이고 OCI DB 홈은 19.11입니다.
$ORACLE_HOME/OPatch/opatch lspatches명령을 실행하여 소스 환경과 대상 환경 모두에 설치된 패치를 식별합니다.$ORACLE_HOME/OPatch/opatch lspatches이 예의 출력은 다음과 같습니다.
온프레미스 DB Oracle 홈 패치 OCI의 DB Oracle HOME 패치 30676209;LNX64-20.1-RAC ASM HIT ORA-07445 EXCEPTION ENCOUNTERED CORE DUMP [KSXPOSDIFQRY()+556]
30613937;IPCOR TOPO 서비스 수정 IP 유형 버그 IP 선택
30484981;OJVM 릴리스 업데이트: 19.6.0.0.200114(30484981)
30489227;OCW 릴리스 업데이트 19.6.0.0.0(30489227)
30557433;데이터베이스 릴리스 업데이트 : 19.6.0.0.200114 (30557433)
29780459;버그 29416368 수정에서 _LM_RES_HASH_BUCKET 및 백아웃 변경 사항 증가
30310195;DBSAT에서 STS_CHUNKS 샤딩을 위해 사용 안함으로 설정된 제약 조건을 GSMADMIN_INTERNAL.SHARD_TS에 보고함
32327201;RDBMS - DSTV36 업데이트 - TZDATA2020E
31335037;RDBMS - DSTV35 업데이트 - TZDATA2020A
30432118;버그를 위한 19.0.0.0.0의 정상에 병합 요청 28852325 29997937
31732095;19C DATABASE ORACLE HOME에서 PERL을 V5.32로 업데이트
32490416;JDK 번들 패치 19.0.0.0.210420
32399816;OJVM 릴리스 업데이트: 19.11.0.0.210420 (32399816)
32579761;OCW 릴리스 업데이트 19.11.0.0.0(32579761)
32545013;데이터베이스 릴리스 업데이트 : 19.11.0.0.210420 (32545013)
- 기존 패치 분석: 일회용 패치를 확인하고, 새 RU 패치에서 패치가 이미 수정되었는지 또는 새 겹치는 패치가 필요한지 검토하고, 제거해야 할 패치를 결정하고, RU에 적합한 패치 파일을 찾습니다.
- 분석에 따라 RU 업데이트를 설치하기 전에 새 RU에서 이미 수정된 일회용 패치를 제거합니다. 그렇지 않으면 충돌이 발생합니다. 이 예제에서는 on-off 패치가 19.11에서 수정되므로 19.11 RU를 설치하기 전에 패치를 롤백해야 합니다.
30676209;LNX64-20.1-RAC ASM HIT ORA-07445 EXCEPTION ENCOUNTERED CORE DUMP [KSXPOSDIFQRY()+556] 30613937;IPCOR TOPO SERVICE FIX IP TYPE BUG IN IP SELECTION - RU 패치를 찾아 다운로드하고 설치합니다. 이 예에서 19.11 RU 패치는 콤보 패치 32578973: COMBO OF OJVM RU COMPONENT 19.11.0.0.210420 + GI RU 19.11.0.0.210420에 있으며 다음과 같습니다.
32399816;OJVM RELEASE UPDATE: 19.11.0.0.210420 (32399816) 32579761;OCW RELEASE UPDATE 19.11.0.0.0 (32579761) 32545013;Database Release Update : 19.11.0.0.210420 (32545013) - OCI DB 홈이 RU 위에 놓인 오버레이, 일회용 패치 및 기타 패치를 찾아 다운로드하여 설치합니다. 예제:
29780459;INCREASE _LM_RES_HASH_BUCKET AND BACK OUT CHANGES FROM THE BUG 29416368 FIX 30310195;DBSAT REPORTED DISABLED CONSTRAINTS FOR SHARDING STS_CHUNKS ON GSMADMIN_INTERNAL.SHARD_TS 30432118;MERGE REQUEST ON TOP OF 19.0.0.0.0 FOR BUGS 28852325 (DSTV33 update) 29997937 (DSTV34 update) 31335037;RDBMS - DSTV35 UPDATE - TZDATA2020A 32327201;RDBMS - DSTV36 UPDATE - TZDATA2020E 32490416;JDK BUNDLE PATCH 19.0.0.0.210420 31732095;UPDATE PERL IN 19C DATABASE ORACLE HOME TO V5.32 - GI 패치에 대해 유사한 분석을 수행합니다.
참고:
- Oracle Data Guard의 관점에서 기본 및 대기 버전에 동일한 GI 버전이 반드시 필요한 것은 아닙니다. Oracle Data Guard는 데이터베이스 아래에 있는 모든 것과 완전히 독립적이므로 버전이나 시간에 대한 제한 없이 여러 사이트에서 여러 버전의 운영 체제, Oracle Clusterware, 하드웨어 또는 스토리지 소프트웨어를 실행할 수 있습니다. (문서 ID 1265700.1)
- Oracle Data Guard에 관계없이 RAC DB의 GI 버전과 RDBMS 버전에 동일한 버전이 있을 필요는 없습니다. 18c부터 Oracle Grid Infrastructure(GI) /Clusterware(CRS) 버전은 항상 가능한 조합의 첫번째 숫자와 같거나 가장 높은 버전이어야 합니다. 예를 들어, Grid Infrastructure는 18.1.0.0에 있고 Database는 18.3.0.0에 있을 수 있습니다. (문서 ID 337737.1)
DB 홈과 동일한 레벨에서 GI에 패치를 적용하는 것이 좋습니다. DB 홈에 최신 RU(릴리스 업데이트) 패치를 적용해야 하는 경우 대부분의 패치는 DB와 GI에 공통되며 동시에 두 홈에 OPatchAuto를 사용할 수 있습니다.