다양한 출처인터넷에서는 각 OS 업그레이드 및/또는 패치 후에 Oracle 바이너리를 다시 연결해야 한다고 제안합니다.
glibc를 업그레이드할 때 다시 연결이 필요하다는 것을 이해합니다. 일부 패키지는 재링크가 필요하지 않을 수도 있고 일부 패키지는 필요하며 일부 패키지는 확실하지 않습니다.
- glibc 업그레이드 -> 다시 연결이 필요한 것 같습니다.
- vim 업그레이드 -> 다시 연결이 필요하지 않은 것 같습니다.
- gzip 업그레이드 -> 잘 모르겠습니다.
- 커널 업그레이드 -> 잘 모르겠습니다
누구든지 목록을 가지고 있습니까? 아니면 Oracle이 실제로 연결하는 라이브러리 목록을 알려줄 수 있는 사람이 있습니까? 저는 Oracle DBA가 아니기 때문에 Oracle 연결 절차에 대해 전혀 모릅니다. 재링크 중에 Oracle이 수행하는 작업을 실제로 이해하고 있는지조차 확신할 수 없습니다. 바이너리 소프트웨어에서는 설치 후 자체 링크를 수행하는 것이 실제로 일반적인 관행은 아닙니다. 그렇죠?
어쨌든 간단히 말해서, 몇 가지 패치를 적용해야 하는 RHEL[345] 상자가 두 개 있습니다. 대부분의 상자는 Oracle을 실행하며 어떤 패치에 다시 연결이 필요하고 어떤 패치에 필요하지 않은지 궁금합니다. 가능한 한 철저한 목록이 좋을 것입니다 :)
답변1
Oracle 데이터베이스를 다시 연결할 필요가 거의 없었습니다. 아마도 주요 O/S 업그레이드 이후나 32비트에서 64비트로 전환한 후에만 가능했을 것입니다. 그러나 의심스러운 경우에는 실행해 보십시오. 1분 정도 걸립니다. 참고할 또 다른 소스는 metalink note 131321.1입니다. 요점은 다음과 같습니다.
" 재연결은 다음과 같은 상황에서 자동으로 발생합니다.
- Oracle 제품은 Oracle 제공 설치 프로그램을 사용하여 설치되었습니다.
- Oracle 패치 세트는 Oracle 제공 설치 프로그램을 통해 적용되었습니다.
Metalink의 '인증' 섹션에 다음 정보가 추가되었습니다.
Oracle Database - Enterprise Edition에 대한 일반 참고 사항:
O/S 정보: 공급업체는 운영 체제 바이너리 호환성을 보장합니다. 따라서 별도로 명시하지 않는 한 이러한 운영 체제를 업그레이드할 때 Oracle 소프트웨어를 다시 설치하거나 다시 연결할 필요가 없습니다.
다음과 같은 상황에서는 Oracle을 수동으로 다시 연결하는 것이 좋습니다(OS 공급업체에서 요구하지 않더라도).
- OS 업그레이드가 발생했습니다.
- OS 시스템 라이브러리가 변경되었습니다. 이는 OS 패치를 적용하는 동안 발생할 수 있습니다.
- 다시 연결 단계에서 새 설치에 실패했습니다.
- 초기 시작 중 개별 Oracle 실행 파일 코어 덤프.
- 개별 Oracle 패치가 적용되었습니다. 그러나 명시적인 재링크 지침은 일반적으로 README에 포함되거나 패치 설치 스크립트에 통합됩니다.
"
답변2
전체 그림을 보려면 위에서 언급한 내용 외에도 Linux 커널을 변경하는 경우 Oracle Clusterware를 다시 연결해야 할 수도 있습니다. 예를 들어 ACFS 파일 시스템을 사용하는 경우 Oracle에는 특정 Linux 커널 버전에 대한 ACFS 커널 드라이버가 있습니다. 하지만 사소한 커널 업그레이드가 이에 적합한지 확실하지 않습니다.
실제로 acfs 클러스터웨어 드라이버를 수정하는 재링크 자체는 아니지만 새 ACFS 드라이버를 설치하는 crs/install/rootcrs.pl -lock(또는 단일 노드 클러스터웨어의 경우 roothas.pl -lock) 스크립트입니다. 클러스터웨어 바이너리를 다시 연결하기 전에 rootcrs.pl -unlock 을 호출해야 하며, 일단 다시 연결이 완료되면 rootcrs.pl -lock 을 호출해야 합니다.
답변3
Oracle Metalink 참고 "Relinking Oracle Home FAQ(자주 묻는 질문)(Doc ID 1467060.1)"가 이미 다른 답변에서 언급되어 있으며 문서의 현재 버전은 다음과 같습니다.
수동 재연결이 필요한 경우는 언제입니까? 아래 상황에서는 수동으로 다시 연결해야 합니다.
A) OS 업그레이드 후 일반적으로 OS 공급업체는 운영 체제 바이너리 호환성을 보장하므로 별도로 명시하지 않는 한 이러한 운영 체제를 업그레이드할 때 Oracle 소프트웨어를 다시 설치하거나 다시 링크할 필요가 없습니다. "그러나 Oracle은 OS 업그레이드 후 Oracle 홈 바이너리를 수동으로 다시 연결하는 것을 권장합니다." 하드웨어를 변경하면 다시 연결할 필요가 없습니다.
B) 운영 체제 패치 후.( 권장 ).
OS 업그레이드, 다운그레이드, 패치 적용 또는 패치 제거 후에 다시 연결해야 합니까? 예, Oracle은 OS 업그레이드, 패치 적용, 다운그레이드 또는 패치 제거 또는 OS 라이브러리 동작에 영향을 미치는 모든 변경 후에 Oracle 홈 바이너리를 수동으로 다시 연결하도록 권장합니다. 성공적인 재링크는 Oracle Executable이 OS 바이너리와 올바르게 연결되었음을 나타냅니다.
Oracle Linux를 사용하는 경우 Redhat Enterprise Linux와 100% 호환됩니다.자주 묻는 질문 Oracle Linux
- Oracle Linux는 Unbreakable Enterprise Kernel을 실행하든 Oracle의 대체 Red Hat 호환 커널을 실행하든 Red Hat Enterprise Linux와 호환되는 애플리케이션 바이너리입니다. 모든 시스템 라이브러리가 변경되지 않은 상태로 유지되므로 기존 애플리케이션은 Unbreakable Enterprise Kernel을 사용하여 변경 없이 실행됩니다.
Red Hat Enterprise Linux 7: 애플리케이션 호환성 가이드.
참고: 주요 릴리스의 수명 주기 동안 Red Hat은 모든 부 릴리스 및 정오표 권고 전반에 걸쳐 핵심 런타임 환경에 대한 바이너리 호환성을 유지하기 위해 상업적으로 합당한 노력을 기울입니다. 필요한 경우 Red Hat은 중요한 영향을 미치는 보안 또는 기타 중요한 문제에 대해 이 호환성 목표에 예외를 둘 수 있습니다. 또한, 위와 부록 A에 설명된 대로 Red Hat Enterprise Linux의 주요 릴리스에는 애플리케이션을 쉽게 마이그레이션할 수 있도록 이전 주요 릴리스에 포함된 제한된 하위 호환 라이브러리 세트가 포함되어 있습니다. 일반적으로 Red Hat은 변경량을 최소화하고 바이너리 호환성을 유지하는 방식으로 변경 사항을 적용합니다. 특정 상황에서는 제어된 패키지 리베이스에 예외가 적용될 수 있습니다.
따라서 Oracle은 변경(패치, 업그레이드 등) 후에 바이너리를 다시 연결하도록 권장하며 Redhat은 "모든 마이너 릴리스에서 핵심 런타임 환경에 대한 바이너리 호환성을 유지하기 위해 상업적으로 합리적인 노력"만 합니다.
바이너리 호환성을 위해서는 OS가 ABI(애플리케이션 바이너리 인터페이스)를 변경하지 않아야 할 뿐만 아니라 애플리케이션이 이 인터페이스만 사용하고 문서화되지 않은 다른 루틴은 사용하지 않아야 합니다.
재연결은 쉬우며 Oracle은 올바른 환경에서 실행되어야 하는 스크립트를 제공합니다. 따라서 실제로 데이터베이스의 시작 스크립트에 연결을 추가하고 데이터베이스를 시작할 때마다 이 연결을 수행할 수 있습니다.
필요한 Linux 패키지는 다음에서 찾을 수 있습니다.Linux용 데이터베이스 설치 안내서섹션에서
- Oracle 데이터베이스 사전 설치 작업
4.8. x86-64 Linux 플랫폼의 운영 체제 요구 사항
4.8.1. x86-64, Linux 7 및 Oracle 12에 대해 지원되는 Oracle Linux 7 및 Red Hat Enterprise Linux 7 배포판.
binutils-2.23.52.0.1-12.el7.x86_64
compat-libcap1-1.10-3.el7.x86_64
compat-libstdc++-33-3.2.3-71.el7.i686
compat-libstdc++-33-3.2.3-71.el7.x86_64
gcc-4.8.2-3.el7.x86_64
gcc-c++-4.8.2-3.el7.x86_64
glibc-2.17-36.el7.i686
glibc-2.17-36.el7.x86_64
glibc-devel-2.17-36.el7.i686
glibc-devel-2.17-36.el7.x86_64
ksh
libaio-0.3.109-9.el7.i686
libaio-0.3.109-9.el7.x86_64
libaio-devel-0.3.109-9.el7.i686
libaio-devel-0.3.109-9.el7.x86_64
libgcc-4.8.2-3.el7.i686
libgcc-4.8.2-3.el7.x86_64
libstdc++-4.8.2-3.el7.i686
libstdc++-4.8.2-3.el7.x86_64
libstdc++-devel-4.8.2-3.el7.i686
libstdc++-devel-4.8.2-3.el7.x86_64
libXi-1.7.2-1.el7.i686
libXi-1.7.2-1.el7.x86_64
libXtst-1.2.2-1.el7.i686
libXtst-1.2.2-1.el7.x86_64
make-3.82-19.el7.x86_64
sysstat-10.1.5-1.el7.x86_64
하지만 이 매뉴얼의 정보가 얼마나 신뢰할 수 있는지는 잘 모르겠습니다. >또한 일부 바이너리에 대해 "ldd" 명령을 실행하여 어떤 라이브러리를 사용하는지 알아낼 수도 있습니다.
$ ldd $ORACLE_HOME/bin/oracle
linux-vdso.so.1 => (0x...)
libodm11.so => $ORACLE_HOME/lib/libodm11.so (0x...)
libcell11.so => $ORACLE_HOME/lib/libcell11.so (0x...)
libskgxp11.so => $ORACLE_HOME/lib/libskgxp11.so (0x...)
librt.so.1 => /lib64/librt.so.1 (0x...)
libnnz11.so => $ORACLE_HOME/lib/libnnz11.so (0x...)
libclsra11.so => $ORACLE_HOME/lib/libclsra11.so (0x...)
libdbcfg11.so => $ORACLE_HOME/lib/libdbcfg11.so (0x...)
libhasgen11.so => $ORACLE_HOME/lib/libhasgen11.so (0x...)
libskgxn2.so => $ORACLE_HOME/lib/libskgxn2.so (0x...)
libocr11.so => $ORACLE_HOME/lib/libocr11.so (0x...)
libocrb11.so => $ORACLE_HOME/lib/libocrb11.so (0x...)
libocrutl11.so => $ORACLE_HOME/lib/libocrutl11.so (0x...)
libaio.so.1 => /lib64/libaio.so.1 (0x...)
libdl.so.2 => /lib64/libdl.so.2 (0x...)
libm.so.6 => /lib64/libm.so.6 (0x...)
libpthread.so.0 => /lib64/libpthread.so.0 (0x...)
libnsl.so.1 => /lib64/libnsl.so.1 (0x...)
libc.so.6 => /lib64/libc.so.6 (0x...)
/lib64/ld-linux-x86-64.so.2 (0x...)
$
하지만 오라클 소프트웨어를 다시 연결하는 것이 더 쉽다고 생각합니다. 이것은 어렵지 않습니다. Metalink 노트에 따르면 변수를 설정하십시오.
ORACLE_HOME
PATH to include $ORACLE_HOME/bin
LD_LIBRARY_PATH $ORACLE_HOME/lib:/usr/lib
그리고 달리다
$ORACLE_HOME/bin/relink all
답변4
내가 제안 할게아니요모든 시나리오에 적합합니다. 나는 항상 재연결은 당신이 당신의 일부를 업그레이드하거나 패치할 때를 위한 것이라는 것을 이해했습니다.신탁지원 운영 체제가 아니라 설치입니다.