EOS를 앞둔 서비스를 사용하고 있는 것은 운영입장에서 매우 아슬아슬한 일이다.
교체에 많은 시간과 비용이 들기 때문에 연초 계획을 잡을 때 반드시 생각해야 하는 중요한 부분이기도 하고.
올해 가장 이슈가 될 대상은 2020년 12월까지만 Flash Player 일 것이다.
OS나 소프트웨어 버전도 EOS를 타기 때문에 각 담당들은 최소한의 비용과 시간으로 이를 해결하기 위해 고군분투할 것으로 생각된다. (시간 드는 것보다 비용 드는 것에 매우 민감하므로 ^_ㅜ)
아 물론 EOS가 이미 도래한 서비스를 계-속 사용하는 경우도 왕왕 봤다.
이번에 포스팅 할 대상은 올해 초 전환작업을 했던 Oracle 19c 버전 업그레이드와 관련한 내용이다.
사실 5월에 작성하다가 임시 저장해둔 글을 발견해서 이제서야 마무리 지어본다. 와우 5개월만이라니..
내가 인프라 담당은 아닌 관계로 전환을 위해 해야하는 다양한 절차에 대해 쓰기보다는 업그레이드 과정에서 알게된 소소한 정보들과 운영 담당으로 우선적으로 챙겨야 하는 것들이 어떤게 있었는지를 순차적으로 작성해볼까 한다.
작성하기에 앞서, 기존에 사용하고 있던 Oracle의 버전 교체가 왜 필요했는지부터 적어본다.
일단 매우 오래된 버전을 사용하고 있었던게 첫 번째 이유다.
처음 Oracle을 사용했을 때도 10g로 시작했던 나에게 9i (심지어 처음에는 8i라고 들어서 올? 하는 느낌까지 듬) 라는 예전 버전을 사용하고 있던 게 조금 충격적이긴 했지만 지금까지 잘 쓰다가 최근 EOS 이슈 때문에 업그레이드를 해야 한다고 했다.
그래서 선택한 버전이 19c다.
왜 19c였냐면... EOS가 가장 늦게 찾아오는 가장 최신의 버전이었기 때문이다.
Oracle에서 제공하는 Release Roadmap을 확인해보면 가장 하단의 2019년 1월부터 시작되는
19c (12.2.0.3) Support 기간을 확인할 수 있다.
//www.koreaoug.org/files/attach/images/206/425/007/3772d18fa39b819854437b62b84a4106.png
출처 : 한국 오라클 사용자 그룹 - 오라클 릴리즈 로드맵
무려 2026년 1월까지 Support가 지원된다고 한다.
일단 그 때까지는 아무런 걱정근심없이 사용할 예정이다. 우리 회사 인프라팀에서 물론 운영을 잘 해주시겠지만 돈 내고 받는 서포트 지원이 빵빵하다는 건 무시못할 든든함이 있다.
아래의 사항들을 차근차근 체크해보자. 물론 전문가인 인프라 담당자들이 잘 해주시겠지만 어플리케이션 영역에서 문제가 될만한 부분이 없는지 크로스 체크를 하는 게 빠른 퇴근의 길.
1. JDK 별 JDBC 버전 확인
현재 사용중인 JDK 버전에 맞는 JDBC 정보 확인이 필요하다.
본인의 경우 9i to 19c라 몇 세대를 건너뛰고 한 번에 넘어가는 거라 매우 불안했던 관계로 해당 사항을 체크해봤다.
역시나 변경이 필요했기 때문에 전환을 계획하시는 분들은 반드시 아래 내용 확인 바란다.
[자료 출처] www.oracle.com/database/technologies/faq-jdbc.html
19C의 경우 JDK 8버전부터 지원하고 있으며, JDK 8~9까지는 ojdbc8.jar를 사용하고
JDK 10~11은 ojdbc10.jar를 사용하면 된다고 한다.
특이하게 JDK11의 경우, 어떤 버전의 jar를 사용해도 무관한 듯 하다.
JDBC별 특징은 아래에 추가한 이미지에 있으나, 크게 중요하게 느껴지진 않는다.
각자 JDK 별 버전에만 맞춰서 추가해주면 되겠다.
[자료 출처] www.oracle.com/database/technologies/faq-jdbc.html
2. SQL 전수 검사
DB 전환 작업을 진행하게 되면 물론 전체적인 쿼리 체크를 진행해봐야한다.
이 경우에는 Oracle to Oracle이라 대부분의 쿼리가 잘 동작한다는 가정하에 프로그램을 전수검사하면 되겠다.
그래도 버전이 변경되는 경우, 지원되지 않는 구 버전의 펑션들이 있을 수 있으므로 지원이 중단되는 대상이 있는지 특이사항만 확인해서 체크하면 큰 문제는 없지 않을까 싶다.
다행히 본인은 해당되는 대상이 없어서 큰 문제 없이 전환했으나, 어마어마한 이슈가 하나 기다리고 있었다.
3. Character set, 인코딩 이슈
다름아닌 인코딩 문제였다. 9i에서 사용하던 모든 세팅을 그대로 옮겨달라고 했는데, 19c에서 지원되지 않는 character set이 있다고 한다. 유사한 걸로 변경해주셨다고 하니, 어쩔 수 없으니 일단 확인해봤는데 별 문제 있겠어 싶었는데 별 문제가 있었다.
기존 데이터 마이그레이션 내용에서 모든 인코딩이 깨져서 나온다 ^_ㅜ 오우 노 오마이갓
그래서 바로 문제 해결 방법을 찾아봤는데 의외로 간단하게 해결가능한 방법이 있다.
그렇지 Oracle은 문제가 없지 해결할 방법을 모두 제공하지 (얼마짜린데)
** 추가로 알고 넘어가면 좋을 Oracle에서 한글을 저장할 수 있는 Charset
상세한 내용은 참고 출처에 표기한 블로그에 아주 상세히 나와있으니 참고하시기 바랍니다.
1) KO16KSC5601
완성형 한글 방식, 일반적으로 많이 사용되며 2350자의 한글, 4888자의 한자, 히라카나, 카타카나, 영문 및 각종 기호를 포함하고 있음
한글자를 표현하기 위해서 2byte를 사용
2) KO16MSWIN949
949라는 익숙한 느낌의 숫자. 웹 페이지 인코딩 방식인 MS949에서 따온 코드셋이라고
한다.
완성형
한글을 포함하여, 조합형까지 총 11172자의 한글을 표현함
한글자를 표현하기 위해서 2byte를 사용
3) UTF8 / AL32UTF8
유니코드 표준 UTF-8 인코딩 체계를 따르는 방식, 11172자의 한글을 지원
Oracle 8i 보다 하위 버전인 경우 UTF8을 사용하며, 그 이상의 경우는 AL32UTF8을 사용한다.
한글자를 표현하기 위해서 3byte를 사용
[참고] db.necoaki.net/134
charset 이름이 기억나면 작성하고 싶은데 지금 너무 오래된 일이라 해결방법밖에 기억나지 않는다.
19c에서 지원되지 않는 구 버전의 charset을 사용하기 위해서 orai18n.jar 파일을
추가해주는 작업을 진행했다.
orai18n.jar 파일은 데이터 타입에 있어서 Oracle의 모든 character set을 지원하기 위한 설정이 포함된 파일이다.
이 파일만 추가해주면 모두 가능 가능
벌써 10월이라니, 이제 연말까지 연휴가 없다니!
올해는 코로나로 뭔가 한 거 없이 빨리 지나간 느낌이다. 사람들도 못만나고, 마스크도 답답하고.
재택 근무, 화상 회의 등 내가 언젠가 겪기나 할까 싶었던 일들이 이번 계기를 통해 갑작스럽게 시작되었고 더불어 IT 환경이 급속도로 커지고 보편화 되어가는 게 느껴진다. 그리고 그 변화의 흐름을 직접 경험한 느낌이라 신기하기도 하고 얼떨떨하기도 하고.
나중에 이 포스팅을 봤을 때는 또 뭐가 바뀌고 있을까. 일단 2020년 다 가기 전에 포스팅을 몇 개는 더 해야할텐데..
다들 오라클 전환도 잘 하시고, 다른 EOS 이슈들도 잘 해결하시기 바랍니다!
오라클 데이터베이스 시작, 종료
FSP 0 770 2020.07.20 09:53
오라클 데이터베이스 시작, 종료
2-2. 데이터베이스시작, 종료
윈도우 환경의 오라클 이라면 제어판의 관리도구, 서비스 메뉴를 이용하여 오라클서버 및 리스너를 실행할 수 있겠지만 다른 환경에서는 SQL*Plus를 이용하여 DB를 시작, 종료해야 한다.
DataBase 종료
- shutdown (normal) : 자주 사용되지 않는 방법으로 사용자의 접속이 끊어질 때 까지 기다려야 한다. 즉 모든 사용자가 자신의 트랜잭션을 끝내고 로그오프 해야만 DB종료가 가능하다.
- shutdown immediate : 가장 자주 사용되는 방법으로 실행중인 SQL문장을 중지하고, 실행중인 트랜잭션이 있으면 RollBack, 사용자의 새로운 로그인을 막고 DB에 변경된 사항을 데이터파일에 기록한다. 사용자들이 로그아웃 할 때까지 기다리지 않고 DB를 종료 한다.
- shutdown abort : 현재 처리중인 모든 명령을 종료, RollBack 하지 않는다. 사용자의 접속을 다 끊고 DB종료, 다음 오라클 시작 시 모든 것들이 복구된다. 그러므로 DB를 abort 옵션으로 종료했다면 정상 시작 후 다시 한번 shutdown immediate로 종료하는 것이 필요하다.
SQL> shutdown abort
SQL> startup
SQL> shutdown immediate
DataBase 시작
- startup nomount : 오라클 인스턴스(백그라운드 프로세스 + SGA) 시작, 데이터베이스생성 또는 컨트롤파일 생성시 이용
- startup mount : 컨트롤파일을 읽고 데이터베이스를 마운트(데이터파일 이름변경, 아카이브로그모드 변경, 데이터베이스 복구등)
- startup open : 사용자 접속가능
- startup restrict : 제한된 모드로 오라클 시작, DB를 정상적으로 시작하지만 User들은 접속불가하며 SQL*Loader로 데이터 로드를 수행, DB upgrade, 데이터의 import, export 수행 시에 주로 이용한다.
- startup force : DB가 시작된 상태라면 자동으로 DB를 종료한 후 다시 시작, 오라클 서버의 비정상적인 종료로 일부 프로세스들이 기동중인 경우 오라클 정상 시작이 안 되는 경우 강제적으로 오라클을 기동하는 시작 옵션.
- alter database mount[open] : 데이터베이스 오픈 상태를 변경
C:\Documents and Settings\A>sqlplus / as sysdba
SQL*Plus: Release 11.2.0.1.0 Production on 일 9월 7 09:45:50 2015
Copyright (c) 1982, 2010, Oracle. All rights reserved.
다음에 접속됨:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> shutdown immediate
데이터베이스가 닫혔습니다.
데이터베이스가 마운트 해제되었습니다.
ORACLE 인스턴스가 종료되었습니다.
SQL> startup nomount
ORACLE 인스턴스가 시작되었습니다.
Total System Global Area 778387456 bytes
Fixed Size 1374808 bytes
Variable Size 285214120 bytes
Database Buffers 486539264 bytes
Redo Buffers 5259264 bytes
-- 현재 DB가 인스턴스만 시작된 nomount 상태임
-- DB를 mount 상태로 변경
SQL> alter database mount;
SQL> alter database open;
SQL> shutdown normal;
데이터베이스가 닫혔습니다.
데이터베이스가 마운트 해제되었습니다.
ORACLE 인스턴스가 종료되었습니다.
-- 이번에는 한번에 DB를 오픈모드까지
SQL> startup open
ORACLE 인스턴스가 시작되었습니다.
Total System Global Area 778387456 bytes
Fixed Size 1374808 bytes
Variable Size 285214120 bytes
Database Buffers 486539264 bytes
Redo Buffers 5259264 bytes
데이터베이스가 마운트되었습니다.
데이터베이스가 열렸습니다.
#오라클시작