pat98's always & forever

Steps to rename the cluster name (Doc ID 2725377.1)

19c (19.3) 부터는 cluster name 을 deconfig 작업없이 바꿀수가 있어 테스트 해봄. 

1. 이름 확인

root:/root> olsnodes -c
gtdb-scan

gtdb-scan에서 gtdb-clu 로 변경해 보겠다.

2. 한쪽에서만 명령수행

root:/root> crsrename cluster gtdb-clu   <----- 명령 실해우  조금 시간이 걸림

CRS-2004: successfully set the cluster name; restart Oracle High Availability Services on all nodes for new cluster name to take effect

3. 양쪽 다 내림
root:/root> crsctl stop crs
CRS-2791: Starting shutdown of Oracle High Availability Services-managed resources on 'gtdb3'
CRS-2673: Attempting to stop 'ora.crf' on 'gtdb3'
CRS-2673: Attempting to stop 'ora.mdnsd' on 'gtdb3'
CRS-2673: Attempting to stop 'ora.gpnpd' on 'gtdb3'
CRS-2673: Attempting to stop 'ora.drivers.acfs' on 'gtdb3'
CRS-2673: Attempting to stop 'ora.driver.afd' on 'gtdb3'
CRS-2677: Stop of 'ora.driver.afd' on 'gtdb3' succeeded
CRS-2677: Stop of 'ora.crf' on 'gtdb3' succeeded
CRS-2673: Attempting to stop 'ora.gipcd' on 'gtdb3'
CRS-2677: Stop of 'ora.gpnpd' on 'gtdb3' succeeded
CRS-2677: Stop of 'ora.mdnsd' on 'gtdb3' succeeded
CRS-2677: Stop of 'ora.drivers.acfs' on 'gtdb3' succeeded
CRS-2677: Stop of 'ora.gipcd' on 'gtdb3' succeeded
CRS-2793: Shutdown of Oracle High Availability Services-managed resources on 'gtdb3' has completed
CRS-4133: Oracle High Availability Services has been stopped.

4. 양쪽 다 올림
root:/root> crsctl start crs -wait
CRS-4123: Starting Oracle High Availability Services-managed resources
CRS-2672: Attempting to start 'ora.mdnsd' on 'gtdb3'
CRS-2672: Attempting to start 'ora.evmd' on 'gtdb3'
CRS-2676: Start of 'ora.mdnsd' on 'gtdb3' succeeded
CRS-2676: Start of 'ora.evmd' on 'gtdb3' succeeded
CRS-2672: Attempting to start 'ora.gpnpd' on 'gtdb3'
CRS-2676: Start of 'ora.gpnpd' on 'gtdb3' succeeded
CRS-2672: Attempting to start 'ora.gipcd' on 'gtdb3'
CRS-2676: Start of 'ora.gipcd' on 'gtdb3' succeeded
CRS-2672: Attempting to start 'ora.cssdmonitor' on 'gtdb3'
CRS-2676: Start of 'ora.cssdmonitor' on 'gtdb3' succeeded
CRS-2672: Attempting to start 'ora.crf' on 'gtdb3'
CRS-2672: Attempting to start 'ora.cssd' on 'gtdb3'
CRS-2672: Attempting to start 'ora.diskmon' on 'gtdb3'
CRS-2676: Start of 'ora.diskmon' on 'gtdb3' succeeded
CRS-2676: Start of 'ora.crf' on 'gtdb3' succeeded
CRS-2676: Start of 'ora.cssd' on 'gtdb3' succeeded
CRS-2672: Attempting to start 'ora.cluster_interconnect.haip' on 'gtdb3'
CRS-2672: Attempting to start 'ora.ctssd' on 'gtdb3'
CRS-2676: Start of 'ora.ctssd' on 'gtdb3' succeeded
CRS-2676: Start of 'ora.cluster_interconnect.haip' on 'gtdb3' succeeded
CRS-2672: Attempting to start 'ora.asm' on 'gtdb3'
CRS-2676: Start of 'ora.asm' on 'gtdb3' succeeded
CRS-2672: Attempting to start 'ora.storage' on 'gtdb3'
CRS-2676: Start of 'ora.storage' on 'gtdb3' succeeded
CRS-2672: Attempting to start 'ora.crsd' on 'gtdb3'
CRS-2676: Start of 'ora.crsd' on 'gtdb3' succeeded
CRS-6023: Starting Oracle Cluster Ready Services-managed resources
CRS-2672: Attempting to start 'ora.proxy_advm' on 'gtdb3'
CRS-6017: Processing resource auto-start for servers: gtdb3
CRS-2672: Attempting to start 'ora.gtdb3.vip' on 'gtdb3'
CRS-2672: Attempting to start 'ora.scan1.vip' on 'gtdb3'
CRS-2672: Attempting to start 'ora.cvu' on 'gtdb3'
CRS-2672: Attempting to start 'ora.ons' on 'gtdb3'
CRS-2672: Attempting to start 'ora.chad' on 'gtdb3'
CRS-2672: Attempting to start 'ora.gtdb4.vip' on 'gtdb3'
CRS-2672: Attempting to start 'ora.qosmserver' on 'gtdb3'
CRS-2676: Start of 'ora.gtdb3.vip' on 'gtdb3' succeeded
CRS-2672: Attempting to start 'ora.LISTENER.lsnr' on 'gtdb3'
CRS-2672: Attempting to start 'ora.LISTENER_TEST.lsnr' on 'gtdb3'
CRS-2672: Attempting to start 'ora.TEST.lsnr' on 'gtdb3'
CRS-2676: Start of 'ora.gtdb4.vip' on 'gtdb3' succeeded
CRS-2676: Start of 'ora.cvu' on 'gtdb3' succeeded
CRS-2676: Start of 'ora.scan1.vip' on 'gtdb3' succeeded
CRS-2672: Attempting to start 'ora.LISTENER_SCAN1.lsnr' on 'gtdb3'
CRS-2676: Start of 'ora.chad' on 'gtdb3' succeeded
CRS-2676: Start of 'ora.LISTENER.lsnr' on 'gtdb3' succeeded
CRS-2676: Start of 'ora.LISTENER_TEST.lsnr' on 'gtdb3' succeeded
CRS-2676: Start of 'ora.TEST.lsnr' on 'gtdb3' succeeded
CRS-2676: Start of 'ora.ons' on 'gtdb3' succeeded
CRS-2676: Start of 'ora.LISTENER_SCAN1.lsnr' on 'gtdb3' succeeded
CRS-2676: Start of 'ora.proxy_advm' on 'gtdb3' succeeded
CRS-2672: Attempting to start 'ora.ORADATA.BOM.advm' on 'gtdb3'
CRS-2672: Attempting to start 'ora.ORADATA.CDC.advm' on 'gtdb3'
CRS-2672: Attempting to start 'ora.ORADATA.SOM.advm' on 'gtdb3'
CRS-2676: Start of 'ora.ORADATA.BOM.advm' on 'gtdb3' succeeded
CRS-2676: Start of 'ora.ORADATA.SOM.advm' on 'gtdb3' succeeded
CRS-2676: Start of 'ora.ORADATA.CDC.advm' on 'gtdb3' succeeded
CRS-2672: Attempting to start 'ora.kwak.db' on 'gtdb3'
CRS-2672: Attempting to start 'ora.velvet.db' on 'gtdb3'
CRS-2676: Start of 'ora.qosmserver' on 'gtdb3' succeeded
CRS-2676: Start of 'ora.velvet.db' on 'gtdb3' succeeded
CRS-2676: Start of 'ora.kwak.db' on 'gtdb3' succeeded
CRS-6017: Processing resource auto-start for servers: gtdb3,gtdb4
CRS-2673: Attempting to stop 'ora.gtdb4.vip' on 'gtdb3'
CRS-2672: Attempting to start 'ora.chad' on 'gtdb4'
CRS-2672: Attempting to start 'ora.ons' on 'gtdb4'
CRS-2677: Stop of 'ora.gtdb4.vip' on 'gtdb3' succeeded
CRS-2672: Attempting to start 'ora.gtdb4.vip' on 'gtdb4'
CRS-2676: Start of 'ora.gtdb4.vip' on 'gtdb4' succeeded
CRS-2672: Attempting to start 'ora.LISTENER.lsnr' on 'gtdb4'
CRS-2672: Attempting to start 'ora.LISTENER_TEST.lsnr' on 'gtdb4'
CRS-2672: Attempting to start 'ora.TEST.lsnr' on 'gtdb4'
CRS-2676: Start of 'ora.LISTENER_TEST.lsnr' on 'gtdb4' succeeded
CRS-2676: Start of 'ora.LISTENER.lsnr' on 'gtdb4' succeeded
CRS-2676: Start of 'ora.chad' on 'gtdb4' succeeded
CRS-2676: Start of 'ora.ons' on 'gtdb4' succeeded
CRS-2676: Start of 'ora.TEST.lsnr' on 'gtdb4' succeeded
CRS-33672: Attempting to start resource group 'ora.asmgroup' on server 'gtdb4'
CRS-2672: Attempting to start 'ora.asmnet1.asmnetwork' on 'gtdb4'
CRS-2676: Start of 'ora.asmnet1.asmnetwork' on 'gtdb4' succeeded
CRS-2672: Attempting to start 'ora.ASMNET1LSNR_ASM.lsnr' on 'gtdb4'
CRS-2676: Start of 'ora.ASMNET1LSNR_ASM.lsnr' on 'gtdb4' succeeded
CRS-2672: Attempting to start 'ora.asm' on 'gtdb4'
CRS-2676: Start of 'ora.asm' on 'gtdb4' succeeded
CRS-33676: Start of resource group 'ora.asmgroup' on server 'gtdb4' succeeded.
CRS-2672: Attempting to start 'ora.ORADATA.dg' on 'gtdb4'
CRS-2672: Attempting to start 'ora.proxy_advm' on 'gtdb4'
CRS-2676: Start of 'ora.ORADATA.dg' on 'gtdb4' succeeded
CRS-2672: Attempting to start 'ora.kwak.db' on 'gtdb4'
CRS-2676: Start of 'ora.proxy_advm' on 'gtdb4' succeeded
CRS-2672: Attempting to start 'ora.ORADATA.CDC.advm' on 'gtdb4'
CRS-2672: Attempting to start 'ora.ORADATA.SOM.advm' on 'gtdb4'
CRS-2676: Start of 'ora.ORADATA.CDC.advm' on 'gtdb4' succeeded
CRS-2676: Start of 'ora.ORADATA.SOM.advm' on 'gtdb4' succeeded
CRS-2672: Attempting to start 'ora.ORADATA.BOM.advm' on 'gtdb4'
CRS-2676: Start of 'ora.ORADATA.BOM.advm' on 'gtdb4' succeeded
CRS-2672: Attempting to start 'ora.velvet.db' on 'gtdb4'
CRS-2676: Start of 'ora.kwak.db' on 'gtdb4' succeeded
CRS-2672: Attempting to start 'ora.kwak.upmu.svc' on 'gtdb4'
CRS-2676: Start of 'ora.kwak.upmu.svc' on 'gtdb4' succeeded
CRS-2676: Start of 'ora.velvet.db' on 'gtdb4' succeeded
CRS-6016: Resource auto-start has completed for server gtdb3
CRS-6016: Resource auto-start has completed for server gtdb4
CRS-6024: Completed start of Oracle Cluster Ready Services-managed resources
CRS-4123: Oracle High Availability Services has been started.
 

5. 이름 확인
root:/root> olsnodes -c
gtdb-clu

6. profile.xml 화일에 변경된 내용 확인

root:/oracle/grid/gpnp/gtdb3/profiles/peer> grep clu profile.xml
<?xml version="1.0" encoding="UTF-8"?><gpnp:GPnP-Profile Version="1.0" xmlns="http://www.grid-pnp.org/2005/11/gpnp-profile" xmlns:gpnp="http://www.grid-pnp.org/2005/11/gpnp-profile" xmlns:orcl="http://www.oracle.com/gpnp/2005/11/gpnp-profile" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.grid-pnp.org/2005/11/gpnp-profile gpnp-profile.xsd" ProfileSequence="8" ClusterUId="5b9302bf58ceefbcffeccf98c169882c" ClusterName="gtdb-clu" PALocation=""><gpnp:Network-Profile><gpnp:HostNetwork id="gen" HostName="*"><gpnp:Network id="net1" IP="172.16.0.0" Adapter="bond0" Use="public"/><gpnp:Network id="net2" IP="10.10.0.0" Adapter="bond1" Use="asm,cluster_interconnect"/></gpnp:HostNetwork></gpnp:Network-Profile><orcl:CSS-Profile id="css" DiscoveryString="+asm" LeaseDuration="400"/><orcl:ASM-Profile id="asm" DiscoveryString="/dev/mapper,AFD:*" SPFile="+ORARECO/spfileASM.ora" Mode="remote" Extended="false"/><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:SignedInfo><ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/><ds:Reference URI=""><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"> <InclusiveNamespaces xmlns="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="gpnp orcl xsi"/></ds:Transform></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><ds:DigestValue>77vX1zi7ocUXFjqmhHbMPiIheF0=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>fGkXizhtfmUzGc7AZuAt88a5YjJlfSyoViTUWT2xj/Xe3WqIEI7yPYo6S0eQO7tWJ9TT2YPmQI6lWHGEDbFA6d0074wHvc0NjCreP3O6i0kgvs/eUFLhQzTuuyFZ5cHSYAx5eLthu7FF7a+jWJzqgTee1VmjoZyTZLaDjpyg9uE=</ds:SignatureValue></ds:Signature></gpnp:GPnP-Profile>

 • 현상
-  RAC 환경에서 LMS Process가 DRM(Dynamic Remastering) 수행 중 ORA-600: [kjbmprlst:shad!res] 에러로 인하여
Terminate되는 현상

• 원인
 - Oracle RAC 19c에서 발생 가능한 Bug.28730044 이슈가 존재 .
- <Note:28730044.8> Bug 28730044 - RAC Instance Crashes With Error ORA-600 [kjbmprlst:shad!res]

• 해결 방안
1. Patch 28730044 적용 권고 (패치 이름에 Exadata라고 되어 있지만, Non-Exadata에서도 발생하므로, 적용 권장)
2. 그러나, 이 이슈에 대한 Fix를 포함하는 DB RU가 없으므로, DB 파라미터로 DRM 기능을 off시키는 것이 권장됨
Workaround :
_gc_policy_time=0, _gc_undo_affinity=0

gridSetup.sh(root.sh) fails with INS-41814 during GI installation on RHEL8/OL8. (Doc ID 2858850.1)

환경 : RHEL 8.3 / 19c RAC 구성

증상 : 

보통 구성중 INS-41814 에러가 나는 모양인데..

내가 겪은 경우에는 CRS 설치 중 1번노드부터  19단계중 거의 다 끝나가는 18단계에서 아래와 같은 로그를 뿌리고 ora.crsd 가 생성되지 못하고 실패함 .

-> 세부적으로는 srvctl add cvu 명령어가 실패함

CLSRSC-504: Executing installationstep 18 of 19: 'ConfigNode'.

PRCT-21011 " "crsctl" 실행을 실패했습니다. 자세한 오류 : CRS-4003: Resource 'ora.crsd' is registered

/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)

해결책 :

해당 경우에는 어이없게도 한글팩은 설치되어 있는데 english locale 이 설치되지 않았음. rhel 8  환경에서는 종종 누락되는 모양이다.

 Install package glibc-langpack-* which include en_US.UTF-8 locale. (eg. glibc-langpack-en)

-> RHEL 8 / OL8 인 경우 en_US.UTF-8 locale 랭귀지 팩을 설치해 줄것.

Exadata DB서버 Core CoD 로 증설 작업 

https://docs.oracle.com/en/engineered-systems/exadata-database-machine/dbmmn/maintaining-exadata-database-servers.html#GUID-6177B070-EF7C-4858-869D-E82C5F8293C0

-> Exadata 모델에 따라 Minimum 수량과 Maximum 수량이 있으므로 사전확인 필요

- CRS 중지 후

1. core 갯수 확인
DBMCLI> LIST DBSERVER attributes coreCount

2. core 수 변경
DBMCLI> ALTER DBSERVER pendingCoreCount = 24

3. core 갯수 확인
DBMCLI> LIST DBSERVER attributes pendingCoreCount

4. 서버 리부팅

5. active Core 확인
DBMCLI> LIST DBSERVER attributes coreCount

추가사항 : Exadata X6 모델인 경우 늘어난 코어가 보이지 않는 Bug 가 있으므로 아래와 같이 사전 조치
Exadata X6 Machine Is Not Showing Increased Corecount Value (Doc ID 2269705.1)

DBMCLI> alter dbserver iaasMode="off"

증상 : SYS 암호 변경시 시도시 ORA-03113 발생하며 에러

SQL> alter user sys identified by <pwd>;
alter user sys identified by <pwd>
*
ERROR at line 1:
ORA-03113: end-of-file on communication channel
Process ID: 898176
Session ID: 3403 Serial number: 31317

Solution :

Oracle DBMS RU 19.12로 업그레이드 했을경우 발생하는 것으로 추정

Patch 31912638 적용 또는

dba_profile의  PASSWORD_REUSE_MAX 와 PASSWORD_REUSE_TIME 을 UNLIMITED 로 변경할것.

MOS : 

ORA-3113 and ORA-7445 [__intel_avx_rep_memcpy()+1088] when altering SYS user password when PASSWORD_REUSE_MAX or PASSWORD_REUSE_TIME has a value (Doc ID 2798582.1)

-- 확인

SQL> select comp_name, version, status from dba_registry;

COMP_NAME                                VERSION         STATUS 
---------------------------------------- --------------- ----------- 
JServer JAVA Virtual Machine             12.1.0.2.0      VALID
Oracle XDK                  12.1.0.2.0      VALID
Oracle Database Java Packages      12.1.0.2.0      VALID

select role from dba_roles where role like '%JAVA%';

select currently_used, name from  dba_feature_usage_statistics where name like '%Java%';

-- JVM 설치

-- Start of File full_jvminst.sql
spool full_jvminst.log;
set echo on
connect / as sysdba
startup mount
alter system set "_system_trig_enabled" = false scope=memory;
alter database open;
select obj#, name from obj$
  where type#=28 or type#=29 or type#=30 or namespace=32;
@?/javavm/install/initjvm.sql
select count(*), object_type from all_objects
   where object_type like '%JAVA%' group by object_type;
@?/xdk/admin/initxml.sql
select count(*), object_type from all_objects
   where object_type like '%JAVA%' group by object_type;
@?/xdk/admin/xmlja.sql
select count(*), object_type from all_objects
   where object_type like '%JAVA%' group by object_type;
@?/rdbms/admin/catjava.sql
select count(*), object_type from all_objects
   where object_type like '%JAVA%' group by object_type;
@?/rdbms/admin/catexf.sql
select count(*), object_type from all_objects
   where object_type like '%JAVA%' group by object_type;
shutdown immediate
set echo off
spool off
exit
-- End of File full_jvminst.sql


-- 객체확인

select owner, count(*) from all_objects
where object_type like '%JAVA%' group by owner;

OWNERCOUNT(*) 
------------------------------ ----------
DMSYS 467
EXFSYS 40
MDSYS 117
ORDSYS   1354
SYS 14987
WKSYS  20

-- JVM 제거

-- Start of File full_rmjvm.sql
spool full_rmjvm.log
set echo on
connect / as sysdba
startup mount
alter system set "_system_trig_enabled" = false scope=memory;
alter system enable restricted session;
alter database open;
@?/rdbms/admin/catnoexf.sql
@?/rdbms/admin/catnojav.sql
@?/xdk/admin/rmxml.sql
@?/javavm/install/rmjvm.sql
truncate table java$jvm$status;
select * from obj$ where obj#=0 and type#=0;
delete from obj$ where obj#=0 and type#=0;
commit;
select owner, count(*) from all_objects
   where object_type like '%JAVA%' group by owner;
select obj#, name from obj$
   where type#=28 or type#=29 or type#=30 or namespace=32;
select o1.name from obj$ o1,obj$ o2
   where o1.type#=5 and o1.owner#=1 and o1.name=o2.name and o2.type#=29;
shutdown immediate
set echo off
spool off
exit

기본으로 PDB를 만들면 CDB를 Startup 했을 때 Open 되지 않고 Mount 상태까지만 올라온다.

귀찮으므로 자동으로 같이 올라오는 Trigger 를 만들어 준다.

SQL*Plus: Release 19.0.0.0.0 - Production on Tue Nov 8 09:38:55 2022
Version 19.3.0.0.0
Copyright (c) 1982, 2019, Oracle.  All rights reserved.
SQL> startup
ORACLE instance started.

Total System Global Area 4932499992 bytes
Fixed Size                  9144856 bytes
Variable Size             939524096 bytes
Database Buffers         3976200192 bytes
Redo Buffers                7630848 bytes
Database mounted.
Database opened.

- 생성

SQL>

create or replace trigger Sys.After_Startup after startup on database
begin
 execute immediate 'alter pluggable database all open';
end After_Startup;
/

Trigger created.

- 지울때는

drop trigger Sys.After_Startup;

패치작업 19.17.0.0.221018 (GI PSU 34416665)

Database Patch Set Update : 19.17.0.0.221018 (34419443)
OCW Patch Set Update      : 19.17.0.0.221018 (34444834)
ACFS Patch Set Update     : 19.17.0.0.221018 (34428761)
Tomcat Release Update     : 19.0.0.0.0       (34580338)
DBWLM Release Update      : 19.0.0.0.0       (33575402)

Oracle Grid Infrastructure Patch Set Update 19.17.0.0.221018 
-------------------------------------
GI_HOME, ORACLE_HOME 을 개별로 각각 할때

- grid 유저
$ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir <UNZIPPED_PATCH_LOCATION>/34416665/34419443
$ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir <UNZIPPED_PATCH_LOCATION>/34416665/34444834
$ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir <UNZIPPED_PATCH_LOCATION>/34416665/34428761
$ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir <UNZIPPED_PATCH_LOCATION>/34416665/33575402
$ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir <UNZIPPED_PATCH_LOCATION>/34416665/34580338

- oracle 유저
$ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir <UNZIPPED_PATCH_LOCATION>/34416665/34419443
$ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir <UNZIPPED_PATCH_LOCATION>/34416665/34444834

(oracle)
$ <ORACLE_HOME>/bin/srvctl stop home -o <ORACLE_HOME> -s <status file location> -n <node name>

(root 유저)
export GI_HOME=/u01/app/19.3.0.0/grid
$GI_HOME/crs/install/rootcrs.sh -prepatch 

(grid 유저)
export GI_HOME=/u01/app/19.3.0.0/grid
cd /u01/install
$GI_HOME/OPatch/opatch apply -oh $GI_HOME -local ./34416665/34444834 -silent
$GI_HOME/OPatch/opatch apply -oh $GI_HOME -local ./34416665/34428761 -silent
$GI_HOME/OPatch/opatch apply -oh $GI_HOME -local ./34416665/34419443 -silent
$GI_HOME/OPatch/opatch apply -oh $GI_HOME -local ./34416665/33575402 -silent
$GI_HOME/OPatch/opatch apply -oh $GI_HOME -local ./34416665/34580338 -silent

(oracle 유저)
export ORACLE_HOME=/u01/app/oracle/product/19.3.0.0/dbhome_1
cd /u01/install
./34416665/34444834/custom/scripts/prepatch.sh -dbhome $ORACLE_HOME
$ORACLE_HOME/OPatch/opatch apply -oh $ORACLE_HOME -local ./34416665/34444834 -silent
$ORACLE_HOME/OPatch/opatch apply -oh $ORACLE_HOME -local ./34416665/34419443 -silent
./34416665/34444834/custom/scripts/postpatch.sh -dbhome $ORACLE_HOME 

(root 유저)
export GI_HOME=/u01/app/19.3.0.0/grid
$GI_HOME/rdbms/install/rootadd_rdbms.sh
$GI_HOME/crs/install/rootcrs.sh -postpatch 

(oracle)
$ <ORACLE_HOME>/bin/srvctl start home -o <ORACLE_HOME> -s <status file location> -n <node name> 

- Loading Modified SQL Files into the Database
sqlplus /nolog
SQL> conect / as sysdba
SQL> startup
SQL> quit
cd $ORACLE_HOME/OPatch
./datapatch -verbose

### [롤백하는 경우] ###########

(oracle)
$ <ORACLE_HOME>/bin/srvctl stop home -o <ORACLE_HOME> -s <status file location> -n <node name>

GI Home
(root로)
$GI_HOME/crs/install/rootcrs.sh -prepatch -rollback

(grid 유저로)
export GI_HOME=/u01/app/19.3.0.0/grid
cd /u01/install
$GI_HOME/OPatch/opatch nrollback -local -id 34444834,34428761,34419443,33575402,34580338 -oh $GI_HOME -silent

(oracle 유저로)
export ORACLE_HOME=/u01/app/oracle/product/19.3.0.0/dbhome_1
cd /u01/install
./34416665/34444834/custom/scripts/prepatch.sh -dbhome $ORACLE_HOME 
$ORACLE_HOME/OPatch/opatch nrollback -local -id 34444834,34419443 -oh /u01/app/oracle/product/19.3.0.0/dbhome_1 -silent
./34416665/34444834/custom/scripts/postpatch.sh -dbhome $ORACLE_HOME

Run post script
(root로)
export GI_HOME=/u01/app/19.3.0.0/grid
$GI_HOME/rdbms/install/rootadd_rdbms.sh
$GI_HOME/crs/install/rootcrs.sh -postpatch -rollback

(oracle)
$ <ORACLE_HOME>/bin/srvctl start home -o <ORACLE_HOME> -s <status file location> -n <node name>

sqlplus /nolog
SQL> conect / as sysdba
SQL> startup
SQL> quit
cd $ORACLE_HOME/OPatch
./datapatch -verbose

갑자기 잘 되면 OEDA 가 화면이 깨지면서 못쓰게 됐다. 어떤 버전은 잘 되고 어떤 버전은 안되고..

Chrome 등의 캐시 문제인줄 알았으나 삽질 하다가 포트를 변경하니 정상적으로 된다...어휴...식빵#$%@RD^%$%

원래 기본 포트로는 7072번이 사용된다.

D:\onecommand\p30640393_2121100_WINNT\windows-i586>installOedaServer.cmd 
Log of actions is located in file : oeda-2022-08-29-225046.log
 Starting HTTP Server ...
 Server URL: http://localhost:7072/oeda
 Server started successfully ...
 Jetty server is accessible locally. To make the server accessible remotely re-install oedaServer using -g flag

이것저것 삽질하다 안되서 7000번으로 바꿔 봄...

성공!!

D:\onecommand\p30640393_2121100_WINNT\windows-i586>installOedaServer.cmd -p 7000
Log of actions is located in file : oeda-2022-08-29-225046.log
 Starting HTTP Server ...
 Server URL: http://localhost:7000/oeda
 Server started successfully ...
 Jetty server is accessible locally. To make the server accessible remotely re-install oedaServer using -g flag

PDU Default Password Changed After Firmware 1.06 and Above on Sun Rack II platforms and Engineered Systems (Doc ID 1570252.1)

-> 가용성 테스트 때문에 한쪽 PDU 만 껏다 켰더니 PDU 양쪽의 암호가 서로 다른 현상으로 고생했다.

Firmware 업그레이드 한 후에 Factory Reset 이 되게 되는데 암호가 달라져서 로그인이 안되는 문제임.

기존의

PUD Firmware 1.05 및 이하는 admin/admin 

-> 문서에는 이렇게 나왔는데 실제로는 admin/welcome1 으로 접속해야지 정상 로그인이 된다.

업데이트 된 

PUD Firmware 1.06 및 이상은 admin/adm1n (알파벳 i 가 아니라 숫자 1로 바뀜)

별로 중요하지도 않은 건데 왜 자꾸 암호를 변경하는지 이해불가하다..절레절레