pat98's always & forever

Cyberpunk: Edgerunners 2 가 제작 된다고 한다.

아마 데이비드는 죽어서 새로운 스토리로 풀어나갈 듯..

Release 된 지는 한참 되었는데 2월에 설치만 해 보고 이제서야 정리해 본다.

영어가 제일 쉬었어요 하는 분들은 아래 메뉴얼을 참고하시기 바란다.

https://docs.oracle.com/en/enterprise-manager/cloud-control/enterprise-manager-cloud-control/24.1/embsc/installing-oracle-enterprise-manager.html#GUID-D0C8EB92-8297-4FF9-A721-BDD2425243C4

우선 EM 설치 진행전 EM Repository DB를 미리 생성해야 하는데 아직 24ai Repository  DB용 Template 가 배포되지 않아서 기존에 배포된 19c Template 지정해서 DB생성하면 Error 발생하므로 Database 생성옵션에서 Custom 선택 후  빈 껍데기 수동으로 생성하여 작업하도록 한다.

시도해 보면 계속 이런 에러가 뜰것이다. 나처럼 해결해 볼려고 하면 정신건강에 좋지 않으니 빨리 포기하도록 하자.

ERROR:The database for which you have provided details already has a valid SYSMAN schema, but not an OPSS schema. Ensure that it also has an OPSS schema. Otherwise, drop the SY[oracle:/tmp/OraInstall2025-02-14_09-08-34AM]

Release 해 놓고 6개월 넘었는데 아직도 Template 제공 안하는건 뭐하자는 건지...개발자들 일해라!!! ..

https://docs.oracle.com/en/enterprise-manager/cloud-control/enterprise-manager-cloud-control/24.1/embsc/creating-database-instance-preconfigured-repository-using-database-templates1.html#GUID-AD704CBD-0C7B-43E6-B413-A87A95FA2722

아무튼 EM 24ai 설치파일은  5개로 구성되어 있다. (현재버전은 24.1)

Repository  DB 가 준비된 상태에서 임치 위치에 모든 설치화일을 올리고  em24100_linux64.bin 을 실행한다.  X환경이 준비되어야 한다.

(압축은 /tmp/임의이름/Disk1, Disk2, ...Disk5 까지 자체적으로 풀림)

(Advanced) 선택

(Skip) 선택 후 [Next >] 선택

호스트 네임에 도메인 네임이 없는 경고 발생, [Ignore] 선택 후, [Next >] 선택

미들웨어 홈 위치 지정 후, [Next >] 선택

Plug-in 선택한 후, [Next >] 선택 (여기서는 Exadata 기준의 Plug-in 선택)

Weblogic Domain, nodemanager 계정, Instance 기본 위치 설정 후, [Next >] 선택

Repository DB 연결 정보 입력 후, [Next >] 선택

수행할 User 지정, [Next >] 선택

사전 요구사항 체크후, [Next] 선택

Custom 으로 Repository Database 생성하였을 경우, 사전조치 사항해야 한다.

SQL> alter system set "_allow_insert_with_update_check"=TRUE scope=spfile;

Repository DB의 유저와 데이터파일 설정. 적당한 값을 입력한 후, [Next]

SW Library  사용유무  선택하고, [Next >] 선택

OMS/Agent가 사용하는 Port 목록. 변경해야 할 필요가 있다면 변경하고, [Next >] 선택

  기본적으로 First available port 를 사용하게 되어 있으나, 보통 upload  Port 는 4889 (http), 1159 (https) 를 지정하며 Console Port 는 7788 (http), 7803 (https) 를 지정하도록 한다. Review 화면, 설정 값들을 확인하고 이상 없다면 [Install] 선택

설치화면 진행..인고의 시간 (워낙 깔리는게 많아서 사양에 따라 3~4시간 소요된다.)

이 후, 설치 진행 화면이 진행되고, 아래의 스크립트를 실행하라는 팝업 창이 뜨면  root 유저로 스크립트를 실행 후, [OK] 선택 하여 팝업 창을 닫고, [Close] 선택하여 설치 종료

설치완료 (설정된 포트 등 확인)

설치가 완료되었다면 접속해 보도록 하자.

https://<EM_HOST_NAME or EM_IP_ADDRESS>:7803/em 

접속해 보면 기존의 오른쪽에 있던 Navigation Menu 가 왼족에 햄버거 버튼으로 대체되었다.

나머지는 메뉴 및 기능은 기존 버전과 거의 유사하다. 

자폐스펙트럼을 아이를 가진 현직 경찰관분이

자폐아를 키우면서 느낀 감정을 따듯하게 표현한 책이다.

놀랍게도 우리나라의 자폐성 장애인의 평균사망연령이 23.8세 라고 한다.

우리나라가 모든 발달장애인이 편견없이 잘 살수 있는 그런 나라가 되었으면 좋겠다. 

김혜민 경찰관님에게 응원을 보냅니다.

19.26 부터 추가된 impdp 옵션 (23ai 에서 사용가능, 정확히는 23.8 부터)

ONESTEP_INDEX 와 INDEX_THRESHOLD 라는 2가지 옵션이 생겼다. 이 두가지 옵션은 서로 같이 사용해야 하는 듯 하다.

1. ONESTEP_INDEX

When TRUE, creates all indexes concurrently with DOP=1 and when

FALSE (the default) uses 2-step process to maximize performance.

2. INDEX_THRESHOLD

Table size (in bytes) where index created with DOP=1 when less

than the threshold and with optimal DOP when greater.

-> default 는 150M

* INDEX_THRESHOLD 에 지정가능한 String 단위는 아래와 같다.

1000B, 100k, 200kb, 100M, 200mb, 100G, 200gb, 100t, 200TB.

이를 이해하기 위해서는 기존의 datapump 사용시 parallel 사용에 대한 이해가 필요하다.

- 11g 경우

PARALLEL=16. Data Pump는 하나의 작업자 프로세스를 사용하여 한 번에 하나씩 인덱스를 생성함 CREATE INDEX ... PARALLEL 16. 이는 큰 인덱스에 효율적..

- 12c 경우

12c에서는 더 많은 인덱스, 특히 여러 개의 작은 인덱스가 있는 스키마에 더 잘 맞도록 알고리즘이 변경됨. Data Pump는 16개의 Woker를 모두 사용하고, 각 Woker를 사용하여 인덱스를 생성. CREATE INDEX ... PARALLEL 1. 

이는 대규모 인덱스의 경우 성능 저하 요인이 될수 있음 .

- 19c (19.26 이상), 23ai

19c, 23ai에서는 이 두가지 이점을 사용할 수 있음. Pump는 테이블 크기를 사용하여 최적의 병렬도를 결정한다. 대규모 배치시는의 최적 병렬도(DOP)를 사용하여 더 작은 인덱스를 생성하고 PARALLEL 1, 최대의 최적 병렬도를 사용하여 더 큰 인덱스를 생성한다. PARALLEL 15

- table 크기가 150 M 이하일 때는 무조건 parallel=1

- 무조건 성능이 좋게 나온다고 보장하지 않기 때문에 운영 시스템 환경에 따라 적절히 테스트 하여 작업할 필요 있음.

Steps to rename the cluster name (Doc ID 2725377.1)

1. cemutlo -n

2. $GI_HOME/bin/crsrename cluster <new_clustername>" <--- 한쪽에서만 실행, 변경될때 시간조금 걸림 30초 정도

3. crsctl stop crs        
4. crsctl start crs -wait 

5. cemutlo -n

=======================================

- 테스트 과정은 아래와 같다.

ocfs-cluster -> test-cluster 로 변경

[root@ocfs1:/root]# cemutlo -n
ocfs-cluster
[root@ocfs1:/root]# crsrename cluster test-cluster
CRS-42004: successfully set the cluster name; restart Oracle High Availability Services on all nodes for new cluster name to take effect

이때 확인해 보면 crsd 는 내려가 있음.

root@ocfs1:/root]# cemutlo -n
/u01/app/19.3.0.0/grid/bin/cemutlo.bin: Failed to initialize communication with CSS daemon, error code 3

[root@ocfs1:/root]# crsctl stat res -t -init
--------------------------------------------------------------------------------
Name           Target  State        Server                   State details       
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.asm
      1        OFFLINE OFFLINE                               STABLE
ora.cluster_interconnect.haip
      1        OFFLINE OFFLINE                               STABLE
ora.crf
      1        ONLINE  ONLINE       ocfs1                    STABLE
ora.crsd
      1        OFFLINE OFFLINE                               STABLE
ora.cssd
      1        OFFLINE OFFLINE                               STABLE
ora.cssdmonitor
      1        OFFLINE OFFLINE                               STABLE
ora.ctssd
      1        OFFLINE OFFLINE                               STABLE
ora.diskmon
      1        OFFLINE OFFLINE                               STABLE
ora.drivers.acfs
      1        ONLINE  ONLINE       ocfs1                    STABLE
ora.evmd
      1        OFFLINE OFFLINE                               STABLE
ora.gipcd
      1        ONLINE  ONLINE       ocfs1                    STABLE
ora.gpnpd
      1        ONLINE  ONLINE       ocfs1                    STABLE
ora.mdnsd
      1        ONLINE  ONLINE       ocfs1                    STABLE
ora.storage
      1        OFFLINE OFFLINE                               STABLE
--------------------------------------------------------------------------------

ohasd daemon 만 떠 있다.

[root@ocfs1:/root]# ps -ef |grep d.bin
root     12800     1  1 12:38 ?        00:00:09 /u01/app/19.3.0.0/grid/bin/ohasd.bin reboot _ORA_BLOCKING_STACK_LOCALE=AMERICAN_AMERICA.US7ASCII
oracle   13092     1  0 12:38 ?        00:00:01 /u01/app/19.3.0.0/grid/bin/oraagent.bin
oracle   13118     1  0 12:38 ?        00:00:00 /u01/app/19.3.0.0/grid/bin/mdnsd.bin
oracle   13152     1  0 12:38 ?        00:00:01 /u01/app/19.3.0.0/grid/bin/gpnpd.bin
oracle   13306     1  0 12:38 ?        00:00:05 /u01/app/19.3.0.0/grid/bin/gipcd.bin
root     13479     1  1 12:38 ?        00:00:06 /u01/app/19.3.0.0/grid/bin/osysmond.bin
root     29355     1  0 12:45 ?        00:00:00 /u01/app/19.3.0.0/grid/bin/orarootagent.bin
root     32424  2837  0 12:48 pts/0    00:00:00 grep --color=auto d.bin

[root@ocfs1:/root]# crsctl stop crs 
CRS-2791: Starting shutdown of Oracle High Availability Services-managed resources on 'ocfs1'
CRS-2673: Attempting to stop 'ora.gpnpd' on 'ocfs1'
CRS-2673: Attempting to stop 'ora.crf' on 'ocfs1'
CRS-2673: Attempting to stop 'ora.drivers.acfs' on 'ocfs1'
CRS-2673: Attempting to stop 'ora.mdnsd' on 'ocfs1'
CRS-2677: Stop of 'ora.drivers.acfs' on 'ocfs1' succeeded
CRS-2677: Stop of 'ora.gpnpd' on 'ocfs1' succeeded
CRS-2677: Stop of 'ora.crf' on 'ocfs1' succeeded
CRS-2673: Attempting to stop 'ora.gipcd' on 'ocfs1'
CRS-2677: Stop of 'ora.mdnsd' on 'ocfs1' succeeded
CRS-2677: Stop of 'ora.gipcd' on 'ocfs1' succeeded
CRS-2793: Shutdown of Oracle High Availability Services-managed resources on 'ocfs1' has completed
CRS-4133: Oracle High Availability Services has been stopped.

[root@ocfs1:/root]# crsctl start crs -wait
CRS-4123: Starting Oracle High Availability Services-managed resources
CRS-2672: Attempting to start 'ora.mdnsd' on 'ocfs1'
CRS-2672: Attempting to start 'ora.evmd' on 'ocfs1'
CRS-2676: Start of 'ora.mdnsd' on 'ocfs1' succeeded
CRS-2676: Start of 'ora.evmd' on 'ocfs1' succeeded
CRS-2672: Attempting to start 'ora.gpnpd' on 'ocfs1'
CRS-2676: Start of 'ora.gpnpd' on 'ocfs1' succeeded
CRS-2672: Attempting to start 'ora.gipcd' on 'ocfs1'
CRS-2676: Start of 'ora.gipcd' on 'ocfs1' succeeded
CRS-2672: Attempting to start 'ora.crf' on 'ocfs1'
CRS-2672: Attempting to start 'ora.cssdmonitor' on 'ocfs1'
CRS-2676: Start of 'ora.cssdmonitor' on 'ocfs1' succeeded
CRS-2672: Attempting to start 'ora.cssd' on 'ocfs1'
CRS-2672: Attempting to start 'ora.diskmon' on 'ocfs1'
CRS-2676: Start of 'ora.diskmon' on 'ocfs1' succeeded
CRS-2676: Start of 'ora.crf' on 'ocfs1' succeeded
CRS-2676: Start of 'ora.cssd' on 'ocfs1' succeeded
CRS-2672: Attempting to start 'ora.cluster_interconnect.haip' on 'ocfs1'
CRS-2672: Attempting to start 'ora.ctssd' on 'ocfs1'
CRS-2672: Attempting to start 'ora.storage' on 'ocfs1'
CRS-2676: Start of 'ora.storage' on 'ocfs1' succeeded
CRS-2676: Start of 'ora.ctssd' on 'ocfs1' succeeded
CRS-2672: Attempting to start 'ora.crsd' on 'ocfs1'
CRS-2676: Start of 'ora.crsd' on 'ocfs1' succeeded
CRS-2676: Start of 'ora.cluster_interconnect.haip' on 'ocfs1' succeeded
CRS-6023: Starting Oracle Cluster Ready Services-managed resources
CRS-6017: Processing resource auto-start for servers: ocfs1
CRS-2672: Attempting to start 'ora.scan1.vip' on 'ocfs1'
CRS-2672: Attempting to start 'ora.ocfs1.vip' on 'ocfs1'
CRS-2672: Attempting to start 'ora.ons' on 'ocfs1'
CRS-2672: Attempting to start 'ora.qosmserver' on 'ocfs1'
CRS-2672: Attempting to start 'ora.chad' on 'ocfs1'
CRS-2672: Attempting to start 'ora.ocfs2.vip' on 'ocfs1'
CRS-2672: Attempting to start 'ora.cvu' on 'ocfs1'
CRS-2676: Start of 'ora.ocfs1.vip' on 'ocfs1' succeeded
CRS-2676: Start of 'ora.ocfs2.vip' on 'ocfs1' succeeded
CRS-2676: Start of 'ora.scan1.vip' on 'ocfs1' succeeded
CRS-2676: Start of 'ora.cvu' on 'ocfs1' succeeded
CRS-2676: Start of 'ora.chad' on 'ocfs1' succeeded
CRS-2676: Start of 'ora.ons' on 'ocfs1' succeeded
CRS-2676: Start of 'ora.qosmserver' on 'ocfs1' succeeded
CRS-6017: Processing resource auto-start for servers: ocfs1,ocfs2
CRS-2672: Attempting to start 'ora.ASMNET1LSNR_ASM.lsnr' on 'ocfs1'
CRS-2672: Attempting to start 'ora.LISTENER.lsnr' on 'ocfs1'
CRS-2672: Attempting to start 'ora.chad' on 'ocfs2'
CRS-2673: Attempting to stop 'ora.scan1.vip' on 'ocfs1'
CRS-2672: Attempting to start 'ora.ons' on 'ocfs2'
CRS-2677: Stop of 'ora.scan1.vip' on 'ocfs1' succeeded
CRS-2672: Attempting to start 'ora.scan1.vip' on 'ocfs2'
CRS-2676: Start of 'ora.chad' on 'ocfs2' succeeded
CRS-2676: Start of 'ora.ASMNET1LSNR_ASM.lsnr' on 'ocfs1' succeeded
CRS-2676: Start of 'ora.LISTENER.lsnr' on 'ocfs1' succeeded
CRS-2676: Start of 'ora.scan1.vip' on 'ocfs2' succeeded
CRS-2672: Attempting to start 'ora.LISTENER_SCAN1.lsnr' on 'ocfs2'
CRS-2676: Start of 'ora.LISTENER_SCAN1.lsnr' on 'ocfs2' succeeded
CRS-2676: Start of 'ora.ons' on 'ocfs2' succeeded
CRS-2672: Attempting to start 'ora.ocfs.db' on 'ocfs1'
CRS-2672: Attempting to start 'ora.ocfs.db' on 'ocfs2'
CRS-2676: Start of 'ora.ocfs.db' on 'ocfs2' succeeded
CRS-2676: Start of 'ora.ocfs.db' on 'ocfs1' succeeded
CRS-6016: Resource auto-start has completed for server ocfs1
CRS-6016: Resource auto-start has completed for server ocfs2
CRS-6024: Completed start of Oracle Cluster Ready Services-managed resources
CRS-4123: Oracle High Availability Services has been started.
[root@ocfs1:/root]# 
[root@ocfs1:/root]# cemutlo -n
test-cluster

Database 서버에서 swapping 을 줄이기 위한 노력

1. 오라클 메모리관리를  AMM -> ASMM 으로 변경

AMM(SGA_TARGET+MEMORY_TARGET)을 사용하는 경우 AMM과 HugePages를 함께 사용할 수 없으므로 ASMM으로 전환한다.

예시)
ALTER SYSTEM SET MEMORY_TARGET=0 SCOPE=SPFILE;
ALTER SYSTEM SET SGA_TARGET=8G SCOPE=SPFILE;
ALTER SYSTEM SET PGA_AGGREGATE_TARGET=4G SCOPE=SPFILE;

2. Transparent HugePages를 사용하면 실행 중에 메모리 할당 지연이 발생하므로 비활성화 작업

cat /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/enabled 

always madvise [never]

3. Hugepages 활성화

SGA 8G 이상 사용하면 설정 권장

1) DB Parameter 를 use_large_pages=only 로 설정

2) grep Hugepagesize /proc/meminfo
   Hugepagesize:       2048 kB

   grep "hugepage" /etc/sysctl.conf
   vm.nr_hugepages=1024

   MOS 문서 401749.1 를 참조하여 hugepages 수를 계산하여 반영

   vi /etc/sysctl.conf
   vm.nr_hugepages=51200 -> 100G 로 설정예시
   
   sysctl -p

4. 오라클 사용계정의 memlock 설정

vi /etc/security/limits.conf

oracle soft nproc 2047 
oracle hard nproc 16384 
oracle soft nofile 1024 
oracle hard nofile 65536

5. OS kernel 변경적용

vi /etc/sysctl.conf
vm.swappiness = 1  -> 낮을수록 더 많은 스왑을 피할 수 있다.
vm.min_free_kbytes = 131072 -> 128M 를 의미

sysctl -p

이 매개변수는 Linux가 예약해야 하는 "사용 가능한 메모리"의 최소 양(KB)을 지정한다. 즉, 시스템은 이 양 이하로 떨어지지 않도록 메모리를 적극적으로 해제한다.
이 값이 낮으면 커널이 메모리를 더 밀접하게 사용하고 갑작스러운 메모리 수요에 대처할 수 없어 스와핑이 발생할 수 있다.
이 값을 어느 정도 늘리면 예방적으로 메모리를 확보하고 스와핑이 발생할 가능성을 줄이는 효과가 있다.

이케아, 라떼파파, 라곰, 복지국가 하면 떠오르는 나라

각자의 문화가 다르기 때문에 한국이 좋다. 스웨덴이 좋다 등의 비교는 의미가 없다.

가장 인상 깊었던 내용은 나와 다름을 인정하고 각자의 개성을 존중한다는 사고방식이였다.

rman 19.25 부터 바뀐 사소한 팁하나.

https://mikedietrichde.com/2025/05/21/rman-speaks-a-bit-more-to-you-since-19-25/

19.25 부터 기존과 달리 rman 접속시 명령어를 실행하면 해당 명령어가 한번 더 디스플레이(ECHO) 되고 에러발생시 Trace 화일도 생성된다..

RMAN> run 
run
2> asdf
asdf

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-00558: error encountered while parsing input commands
RMAN-01009: syntax error: found "identifier": expecting one of: "{"
RMAN-01008: the bad identifier was: asdf
RMAN-01007: at line 2 column 1 file: standard input
RMAN Client Diagnostic Trace file : /u01/app/oracle/diag/clients/user_oracle/RMAN_393717041_110/trace/ora_rman_63173_0.trc

이는 Bug 가 아니며 잘못된 RMAN 명령어 작성시 메모리 내에 추적을 생성하고 디스크로 플러싱 하기 위한 의도적인 것이라고 한다. <--- 로그 분석을 원활하게 하기 위함..(Trace 화일은 30일 동안 보존되고 자동으로 삭제된다고 한다.)

명령어가 한번더 보이는게 싫고 이전 방식대로 사용하고 싶다면 명령어 사용전에
RMAN> set echo off

하고 진행하면 된다. 19.25 부터 ECHO 가 ON 으로 바뀌어서 OFF 로 바꾸는 것은 권장하지 않는다고 한다.

또한 Trace 화일 생기는 것은 없앨 수 없다고 한다.

Starting DBRU 19.27 and 23.8 Small Pages Are Not Allowed for RDBMS SGA In Exadata. (Doc ID 3081878.1)

(단 일반 시스템은 아니고 Exadata 만 해당된다)

바뀐 이유 : 

SGA를 위해 작은 페이지를 사용하면 VM(데이터베이스 인스턴스가 실행 중인) 내부와 하이퍼바이저에 페이지 테이블과 RDMA 리소스 메모리 블롯이 생성된다. 이는 DB 노드에 불안정을 초래하고 해당 DB 노드의 모든 인스턴스에 문제를 일으킬 수 있다.

기존 Small Pages 를 사용할 경우 설정값에 따라 alertlog에 아래와 같이 Error 발생함.

2025-05-19T10:44:27.233650+09:00
Instance shutdown complete (OS id: 274904)
2025-05-19T10:44:36.634051+09:00
Starting ORACLE instance (normal) (OS id: 283360)
2025-05-19T10:44:36.645269+09:00
ERROR: use_large_pages = TRUE is not a supported setting for database on Exadata
2025-05-19T10:44:36.645326+09:00
       : suggested values are AUTO_ONLY or ONLY

기본 리눅스 Memory Page s기본값 : 4k

Exadata Memory Page s기본값 : 2048K

※ 메모리 블롯 (bloat)은 프로그램이 의도한 작업을 실행하는 데 필요한 것보다 더 많은 메모리를 사용하는 상황을 말함.
일반적으로 메모리 최적화 불량, 과도한 데이터 캐싱 또는 중복 객체의 축적으로 인해 발생하는데 이는 결과적으로 프로그램의 메모리 사용량이 증가하여 성능 저하 및 잠재적인 속도 저하로 이어진다.

Database Generating Large Amount Of Redo After Applying Jan 2025 DBRU (37260974) (Doc ID 3073478.1)

19.26 (2025년 1월) 패치를 적용하고 난 후 부터 이전과 달리 redolog 발생량이 급격하게 증가하는 문제 발생

- 버그는 아니며 19.26 부터 DB_LOST_WRITE_PROTECT 값이 AUTO 로 셋팅되면서 발생하는 문제임.

기존과 같이 NONE 으로 관리하려면 아래와 같이 조치해준다.

(재기동 필요없음. 현재 세션부터 영향받음)

SQL> alter system set db_lost_write_protect='NONE';

※ 특히 dataguard 를 운영하는 환경에서는 고민이 필요한 값이 되겠다.