독까의 이야기

오라클 12c 설치를 해봤으니깐, 삭제 하는 것도 테스트를 한다. 

기본은 11g 삭제때와 동일하다.


# 1 

오라클 프로그램 항목들 중에서, Universal Installer 를 실행한다.


프로그램이 실행되면, "제품 설치 해제" 를 클릭한다.


설치 되어 있는 제품 체크 후, 제거 버튼 누른다. 


그러면 11g 때와 마찬가지로 경고창 호출 된다. 배치 파일 실행해서 삭제하라는 얘기다. 한결 같은 오라클이다. 



# 2

경고창이 시키는대로 배치 파일 실행하러 경로 이동한다.

D:\app\Administrator\product\12.2.0\dbhome_1\deinstall

CMD 를 관리자 모드로 실행해서 배치 파일 실행하던,  파일 탐색기에서 deinstall.bat 를 관리자 권한으로 실행하던 알아서 하면 된다. 

나는 그냥 CMD 에서 한다. 


뭐 하라고 나오면 그냥 Default 로 쭉쭉 진행하면 된다. 


몇 분 지나니깐 삭제 다 됐다고 나온다. 



# 3

CMD 에서 sqlplus 실행 및 1521 리스너 체크해도 아무것도 안나온다. 


서비스 목록에서도 안 보인다. 안 보이는데 캡처하면 무쓸모니깐 생략한다.


11g 때와 마찬가지로, 완전 삭제를 위해서 오라클 폴더 및 관련 레지스트리까지 삭제한다.

레지스트리 편집기 실행 후, 찾기 : oracle 입력 후, F3 계속 누르면서 나오는 오라클 12c 관련 항목 다 삭제해버리면 된다. 

java 나 oledb 관련 삭제하면 안 됨. 

리부팅 1회 하면 끝난다. 

뭐 삭제도 어려운거 아니니깐 그냥 해보면 된다. 

오라클 12c 는 2013년에 출시가 되었지만, 대부분의 개발사들은 11g 를 주로 사용하고 있다.

이번에는 12c 설치 테스트를 한다. 


OS : Windows Server 2016

DBMS : Oracle 12c R2


# 1

우선 오라클 사이트에 접속해서 설치 파일을 다운로드 받는다. 오라클 계정이 있어야 다운로드 된다. 

https://www.oracle.com/kr/database/technologies/oracle12c-windows-downloads.html



다운로드 된 압축파일을 해제하고, setup.exe 클릭해서 설치 진행한다. 


오라클은 GUI 환경으로만 설치가 되기 때문에, 모니터 구성을 확인하는 창이 뜬다. 


1/10 보안 갱신 구성은 전부 스킵한다. 필요없다. 


2/10 "데이터베이스 생성 및 구성" 선택 후 넘어간다.


3/9 "서버 클래스" 선택 후 넘어간다.


4/11 "단일 인스턴스  데이터베이스 설치" 선택 후 넘어간다.


5/11 "표준 설치" 롤 선택 후 넘어간다. 설치 테스트 목적이므로 고급 단계는 불필요하다. 


6/11 Default 값으로 선택 후 넘어간다. 뭐 본인이 따로 계정 사용하고 싶으면 입력해도 된다. 


7/11 설치 될 경로 및 DB 버전을 선택한다. 

Default 값이 virtual 로 되어 있는데, 일반값으로 변경한다. 

비밀번호는 숫자, 영문 대소문자 조합해서 입력해야 한다. 

"컨테이너 데이터베이스로 생성" 은 체크 해제한다. 불필요하다.


8/11 필요 조건 검사가 정상 완료되었다.


9/11 설치 버튼 누르고 대기한다. 



설치가 완료되면, 서비스 리스트에 추가 내역 확인 할 수 있다. 

OracleServiceORCL 및 OracleOraDB12Home1TNSListener 만 실행되면 되고, 나머지는 전부 "사용 안 함" 으로 변경해도 된다.


오라클 리스너가 정상 작동 중인지 CMD netstat 으로 확인한다.

  TCP    0.0.0.0:1521           0.0.0.0:0              LISTENING

 [TNSLSNR.exe] 



# 2

CMD 를 이용해서 오라클 인스턴스에 접속한다.

컬럼 사이즈가 작으면, 자동 줄 바꿈이 되버리니깐 사이즈도 변경한다.


접속되어 있는 인스턴스를 확인한다. 

SQL> SELECT NAME, DB_UNIQUE_NAME FROM v$database;

NAME               DB_UNIQUE_NAME

------------------ ------------------------------------------------------------

ORCL               orcl 


주요 구성 파일의 경로를 확인한다. 

SQL> select name from v$controlfile;

NAME

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------

D:\APP\ADMINISTRATOR\ORADATA\ORCL\CONTROL01.CTL

D:\APP\ADMINISTRATOR\ORADATA\ORCL\CONTROL02.CTL



SQL> select file_name from dba_data_files;

FILE_NAME

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------D:\APP\ADMINISTRATOR\ORADATA\ORCL\USERS01.DBF

D:\APP\ADMINISTRATOR\ORADATA\ORCL\UNDOTBS01.DBF

D:\APP\ADMINISTRATOR\ORADATA\ORCL\SYSTEM01.DBF

D:\APP\ADMINISTRATOR\ORADATA\ORCL\SYSAUX01.DBF



SQL> select group#,member from v$logfile;

GROUP#----------MEMBER----------------------------------------------------------------------------------------------------------------------------------------------- 3                     D:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO03.LOG

2                     D:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO02.LOG

1                     D:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO01.LOG



SQL> show parameter spfile;

NAME                                 TYPE                   VALUE

------------------------------------ ---------------------- ------------------------------

spfile                               string                 D:\APP\ADMINISTRATOR\PRODUCT\1

                                                            2.2.0\DBHOME_1\DATABASE\SPFILE

                                                            ORCL.ORA 


외부에서도 오라클 인스턴스 접속 정상 확인 된다. 



# 3

설치 방법 및 접속은 11g 와 크게 차이는 없다. 

클러스터 및 RAC 추가 기능이 있지만, 굳이 테스트 할 필요는 없을 것 같다. 


이어서 AlwaysOn  가용성 그룹 구축을 진행한다.

전 글에서 진행한 방식은 기존 SQL 미러링 구성과 유사하다. 

주 와 보조 간의 데이타 동기화 및 장애 발생시 역할 변경이 동일하다고 볼 수 있다. 

- OS : Windows Server 2016

- DBMS : MS SQL Server 2016 SP2

- 테스트 서버 : AO_TEST_01 (192.168.1.121) / AO_TEST02 (192.168.1.122) 

- 클러스터 IP : 192.168.1.123 

- 수신기 IP : 192.168.1.125

- 방화벽 정책 추가 : In/Outbound : TCP 135, 445, 3343 / UDP 3343

- 공인 아이피로 구성할 때에는 각 서버의 C:\Windows\System32\drivers\etc\hosts 파일의 내용을 필히 아래와 같이 수정

192.168.1.121 AO-TEST-01

192.168.1.122 AO-TEST-02

192.168.1.123 AOT

 

이번에는 이 구성에 VIP 를 추가하여, 주와 보조의 역할이 변경되더라도 동일한 IP 로 DB 에 접근이 가능하도록 구성한다.

"가용성 그룹 수신기" 를 구성하면 우리가 필요한 기능을 사용 할 수 있다. 

 

 

# 1

AO_TEST_01 의 SSMS 에서 가용성 그룹 - AO_DB - 우클릭 - 수신기 추가 를 선택한다. 

하위 트리의 가용성 그룹 수신기 에서 우클릭해서 만들어도 된다.

 

 

수신기 DNS 이름은 AO_DB 그룹에서 사용되는 고유값을 작성해야 한다.

가용성 그룹은 다중 등록이 가능하므로, 해당 그룹에서만 사용되는 고유 수신기를 등록해야 한다.

수신기 DNS 이름 : AO_Listener 

포트 : 1433

네트워크 모드 : 고정 IP

IP 주소 : 192.168.1.120

 

한 번에 쉽게 됐으면 테스트를 당연히 안하겠지만, 또 오류 나와버린다.

윈도우 장애 조치 클러스터 어쩌구 저쩌구 오류인데, 클러스터 상태는 정상이다. 

 

아이피를 바꿔서 다시 해본다. 

IP 주소 : 192.168.1.100 

 

수신기 생성 진행 중일 때, 클러스터 관리자의 상태는 아래와 같이 표시된다

 

또 오류 뜨면서 실패한다. 

다시 아이피 바꿔서 입력한다.

IP 주소 : 192.168.1.125 

 

이번에도 오류가 뜨지만 내용이 다르게 나온다. 

DNS 어쩌구 저쩌구란다. AD 구성시 설정하던 DNS 가 갑자기 튀어 나온다. 

 

MS 기술 문서에서 상세 내용을 훑고 온다. 

https://docs.microsoft.com/ko-kr/sql/database-engine/availability-groups/windows/create-or-configure-an-availability-group-listener-sql-server?view=sql-server-ver15

AD 에서 소속 그룹에 도메인을 추가 하듯이, AO 구성 서버에도 DNS 접미사 및 NetBIOS 컴퓨터 이름이 필요하다는 얘기다. 

그럼 추가 하러 간다. AO_TEST_01 과 AO_TEST_02 둘 다 해야한다.

 

시스템 속성 - 변경 - 자세히 - 이 컴퓨터의 주 DNS 접미사 에 "값" 입력 / "도메인 구성원 자격이 변경되면 주 DNS 접미사 변경" 항목 체크

적용하고 리부팅 1회 진행한다.

 

 

 

다시 SSMS 랑 클러스터 관리자 실행한다.

수신기 추가 단계로 다시 간다.

수신기 DNS 이름 : AO_Listener 

포트 : 1433

네트워크 모드 : 고정 IP

IP 주소 : 192.168.1.124

 

당연히 또 오류가 나겠거니 했는데 진짜 나온다. 

이번에는 리소스 제어 API 가 오류 코드 5057 을 보냈단다. 

 

sql error 41009 로 구글링 하니깐 외국 SQL 전문가 분이 작성한게 나왔다. 

그래서 따라한다. 

cmd 켜서 "net helpmsg 5057" 입력한다.

 

 

 

 

 

내가 입력한 IP 가 이미 사용 중이란다. 고민하지 말고 그냥 다른 아이피 넣는다. 

IP 주소 : 192.168.1.125 

 

이번에는 오류 없이 처리가 됐다. 로딩이 길어져서 실패인가 했는데 정상적으로 구성 됐다. 

안 될 때는 그냥 계속 아이피 변경해서 넣는게 답이다. 

 

 

AO_TEST_01 에서 아이피 조회시, 클러스터 및 리스너 IP 를 소유하고 있음을 확인 할 수 있다.

 

 

# 2

속칭 VIP 구성까지 완료가 되었으니깐 장애 조치 (Failover) 를 순차적으로 해본다.

 

1) AO_TEST_01 서버 전원 OFF

 

AO_TEST_01 전원 OFF 된 후의 상태이다. 

클러스터 호스트 및 소유자, 클러스터 IP, 리스너 IP 모두 AO_TEST_02 가 소유하고 있다. 

 

 

AO_TEST_02 의 SSMS 에서도 변경 된 역할 확인 된다.

 

2) SSMS 에서 장애 조치 진행

 

AO_TEST_02 가 주 로 역할이 변경되었으니깐, 다시 AO_TEST_01 을 주 로 변경하는 작업을 한다.

서버 전원 OFF 로 하는 것은 위에서 했으니깐, AO_TEST_01 서버 전원을 올리고 SSMS 에서 역할 변경을 진행한다.

 

정상 완료 후, AO_DB 클러스터 소유자 및 서버 할당 아이피를 확인한다.

 

AO_TEST_01

 

AO_TEST_02

 

클러스터 IP 는 AO_TEST_02 가 소유하고 있고, 리스너 IP 는 AO_TEST_01 이 소유하고 있음을 알 수 있다. 

 

 

# 3

위 두 가지 방식의 장애 조치 (Failover) 테스트만 진행해도 어떤 구조로 돌아가는지는 이해됐을 테니깐 여기서 종료한다.

윈도우 자체 기능을 통한 DB 이중화 및 장애 조치 클러스터를 구축했는데, 관건은 DB 서버간 데이타 전송시의 속도와 트래픽량이다.

서버끼리 사설 네트워크 구성해서 해당 구간으로는 실시간 동기화를 진행하고, 공인 네트워크로는 DB 커넥션만 되도록 구성하면 어느 정도 해결은 될 것 같다.

SQL 2016 AlwaysOn 에 추가 된 기능 중, 보조 영역을 "읽기 전용" 으로 구성하여 분산 처리하는 방식은 나~중에 시간 나면 해보자.