Install, patch, 트러블 슈팅 으로 구분 등으로 분류 하겠습니다.
ORA-32000: write to SPFILE requested but SPFILE is not modifiable
--> SPFILE 수정 불가능 하면서 완전 당황 그 차체를 만들어 봅니다.
이런경우가 발생 할 수 있을까 ??
네 있네요..
특히 RAC 인경우... 패치와 연관 있었습니다.
|
ORA-32000 not able to modify the rdbms spfile which is there in ASM (문서 ID 1498307.1) CRS-6706: Oracle Clusterware Release patch level ('nnn') does not match Software patch level ('mmm') (문서 ID 1639285.1) --> 첨부파일 참고
About Oracle ASM Rolling Patches: https://docs.oracle.com/database/121/OSTMG/GUID-CF124D9F-FF28-4B71-B179-640F1258E98A.htm#OSTMG95330 --> 12cR1 이상 부터 보이는듯 합니다.
|
실질적으로 ASM DISK GROUP 확인 결과 SPFILE 존재 함..
바로 의심을 해야 할 부분및 점검 내용은 아래와 같습니다.
발생될수 있는 이슈 : 1) spfile 수정 불가 , 2) ASM DISKGROUP 추가 삭제시 오류발생 소지 있음.
발생 원인 : 1) 패치가 잘못 되어 롤백을 했으나 제대로 롤백이 되지 않을때 발새 될 수 있음.
2) 양쪽 노드 패치가 다른 경우 발생 할수 있습니다. ( 즉 RAC 인 경우 : 1번노드는 4월 CPU, 7월 CPU 모두 적용 , 2번 노드는 7월달만 적용 된경우 )
-> 전 실질적으로 이 경우 문제 발생 후 조치 완료.
명령어를 나열 해 봅니다.
RAC 기준입니다.
1) 패치 점검
opatch lsinventory | grep Patch
맨아래에...
Patch level status of Cluster nodes :
Patching Level Nodes
-------------- -----
3696455212 db1 ---->> 서로 다른 패치 레벨
3705364692 db2 ---->> 서로 다른 패치 레벨
---> 위의 패치 레벨은 반드시 동일 하게 되어야 하는데 번호가 다릅니다.
/-- **
정상인 경우는 아래와 같습니다.
Patch level status of Cluster nodes :
Patching Level Nodes
-------------- -----
3705364692 db1,db2
-- **/
2)SYS_CONTEXT 확인 방법
SELECT SYS_CONTEXT('SYS_CLUSTER_PROPERTIES', 'CLUSTER_STATE') FROM DUAL;
SYS_CONTEXT('SYS_CLUSTER_PROPERTIES','CLUSTER_STATE')
--------------------------------------------------------------------------------
In Rolling Patch
-->>> In Rolling Patch 상태 인것을 확인 함. (정상 : Normal )
3) 노드 패치 점검
[+ASM1]root@db1:/oracle/12.1.0/grid/crs/install> kfod op=patches
---------------
List of Patches
===============
19769480
20299023
20831110
21359755
21436941
21948354
22291127
23054246
23054327
23054341
[+ASM1]root@db1:/oracle/12.1.0/grid/crs/install> kfod op=patchlvl
-------------------
Current Patch level
===================
3696455212 --> *****
[+ASM1]root@db1:/oracle/12.1.0/grid/crs/install>
[+ASM2]root@db2:/oracle/12.1.0/grid/crs/install> kfod op=patches
---------------
List of Patches
===============
19769480
20299023
20831110
21359755
21436941
21948354
22291127
22502518 -> *******
22502555 -> *******
23054246
23054327
23054341
[+ASM2]root@db2:/oracle/12.1.0/grid/crs/install> kfod op=patchlvl
-------------------
Current Patch level
===================
3705364692 --> *****
[+ASM2]root@db2:/oracle/12.1.0/grid/crs/install>
4) 패치 이력 조회
[+ASM1]grid@db1:/oracle/12.1.0/grid/cfgtoollogs/opatch> pwd
/oracle/12.1.0/grid/cfgtoollogs/opatch
[+ASM1]grid@db1:/oracle/12.1.0/grid/cfgtoollogs/opatch>
[root@db1 opatch]# egrep "Patching Level" *.log
~~~ 쭉 펼쳐 지면서 뭔가 나오겠네요.... ( 안 지웠으면.. )
-- history 조회도 해 봅니다.
egrep "apply " opatch_history.txt
조치방법
1안 ) - 조치 불가 했음
/u01/grid/app/product/12/crs/install] ./rootcrs.sh -patch
양쪽 노드 모두 동일 하게 수행 하면 내렸다 올림.
확인 방법.
crsctl query crs activeversion -f
crsctl stop rollingpatch
--> NORMAL 아닌 경우 즉 (=ROLLING PATCH )적용 여부 검토
grid db 상에서 확인.
SELECT SYS_CONTEXT('SYS_CLUSTER_PROPERTIES', 'CLUSTER_STATE') FROM DUAL;
--> Normal 이 아닌경우 즉(=In Rolling Patch) 적용 여부 검토
ALTER SYSTEM STOP ROLLING PATCH;
2안 ) - 조치 완료 후 정상
위에서 보시면 1번 NODE가 최신 레벨이 아닌것으로 판단이 되어서 무조건 1번도느들 맟추는 작업을 진행 해야 합니다.
전 노드 패치 이력등을 꼼꼼히 살펴야 합니다.
필요시 패치롤백 도 진행 해야 하기도 합니다.
예로 ) 2번노드에서 4월달 패치 완료 -> 7월달 패치 완료 순으로 되어 있다면..
1번노드에서는 4월달 패치가 없고 7월달 패치만 존재 하게 되면
7월달 패치 롤백 후 4월달 패치 적용 -> 7월달 패치 적용 순으로 하시면 됩니다.
정상적으로 처리 후 확인 방법은 아래와 같습니다.
[+ASM1]grid@db1:/oralog/pkg/160519> crsctl query crs activeversion -f
Oracle Clusterware active version on the cluster is [12.1.0.2.0]. The cluster upgrade state is [NORMAL]. The cluster active patch level is [3705364692].
[+ASM1]grid@db1:/oralog/pkg/160519>
sqlplus /as sysdba
--
SQL> SELECT SYS_CONTEXT('SYS_CLUSTER_PROPERTIES', 'CLUSTER_STATE') FROM DUAL;
SYS_CONTEXT('SYS_CLUSTER_PROPERTIES','CLUSTER_STATE')
--------------------------------------------------------------------------------
Normal
SQL> SELECT SYS_CONTEXT('SYS_CLUSTER_PROPERTIES', 'CURRENT_PATCHLVL') FROM DUAL;
SYS_CONTEXT('SYS_CLUSTER_PROPERTIES','CURRENT_PATCHLVL')
--------------------------------------------------------------------------------
3705364692
SQL>
근데 왜 이런 현상이 발생 되었을까요 ?
1). 직접 패치 작업을 안 하고 누가 한것을 보기만 하고 점검 도 안 한 경우
2) 패치 작업 중 실수로 특정 노드 작업을 빼 먹은 경우
Good~~