오라클 12c 설치 (윈도우 환경)
오라클 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 추가 기능이 있지만, 굳이 테스트 할 필요는 없을 것 같다.
'Database > Oracle' 카테고리의 다른 글
| 오라클 12c 제거 (윈도우 환경) (0) | 2020.08.05 |
|---|---|
| [오라클] 오라클 클라이언트 제거 (0) | 2016.12.08 |
| [오라클] Oracle 11g R2 x64 클라이언트 설치 (0) | 2016.12.08 |
| [오라클] 오라클 11g 제거 (윈도우 환경) (0) | 2016.08.12 |
| [오라클] 오라클 11g 설치 (윈도우 환경) (0) | 2016.08.12 |
AlwaysOn 가용성 그룹 구축 # 2 : Windows Server 2016 + MS SQL 2016 / None AD
이어서 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 기술 문서에서 상세 내용을 훑고 온다.
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 에 추가 된 기능 중, 보조 영역을 "읽기 전용" 으로 구성하여 분산 처리하는 방식은 나~중에 시간 나면 해보자.
'Database > MS-SQL' 카테고리의 다른 글
| MSSQL DML 로그 저장 설정 (0) | 2024.06.28 |
|---|---|
| MSSQL 업그레이드 (1) | 2022.11.04 |
| AlwaysOn 가용성 그룹 구축 # 1 : Windows Server 2016 + MS SQL 2016 / None AD (6) | 2020.07.03 |
| SQL DB 암호화 / TDE(Transparent Data Encryption) (0) | 2018.12.07 |
| MS-SQL CPU 사용량이 높은 쿼리문 확인 (0) | 2018.06.22 |
AlwaysOn 가용성 그룹 구축 # 1 : Windows Server 2016 + MS SQL 2016 / None AD
예전에 AD 로 구축 된 서버군에서 SQL 장애 조치 테스트를 진행 했었다.
이번에는 AD 가 구축되지 않은, 윈도우와 SQL 만 설치 된 서버들로 DB 장애 조치 테스트를 진행한다.
Windows Server 2016 + MS SQL Server 2016 이후 부터는 AD 없이 클러스터 구성 가능하다.
따라서 아래의 환경으로 테스트를 진행한다.
- 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
- 방화벽 정책 추가 : 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 |
# 1
신규 설치 된 테스트 서버 두 대 접속 후, 역할 및 기능 추가 마법사에서 "장애 조치 클러스터링" 설치한다.
그냥 Default 로 설치하면 된다.
# 2
MS SQL Server 2016 을 설치한다. 이것도 Default 로 설치하면 된다.
두 서버의 DB 데이타 저장 경로가 일치해야 하므로 아래와 같이 설정한다.
2016 이후부터는 설치 패키지에 SSMS 가 포함되어 있지 않으므로, 링크에서 다운로드 한다.
SQL 서비스 로그온 계정은 반드시 사용자 계정으로 변경한다.
AO_TEST_01 과 02 모두 동일한 계정 정보를 갖고 있어야 한다.
# 3
클러스터 생성 단계로 넘어간다.
관리도구에서 "장애 조치 클러스터 관리자" 를 실행 한다.
AO_TEST_01 이나 AO_TEST_02 아무데서나 생성해도 된다.
테스트 서버 상호간에 완전 통신이 가능하도록 방화벽 인바운드 정책 추가해야 한다.
클러스터에 포함 될 서버의 아이피를 차례대로 입력한다.
아이피 추가하면 컴퓨터명으로 서버 리스트가 호출된다.
유효성 검사 경고 단계에서는 "아니요" 선택해서 넘어간다.
클러스터 이름은 "AOT" 로 생성한다. 뭐 아무거나 입력해도 상관없다. 본인이 알아볼 수 있으면 된다.
아이피에는 192.168.1.123 을 입력한다. 해당 아이피가 클러스터 IP 가 된다.
Default 로 쭉쭉 넘어가면 클러스터 만들기 완료 된다.
AO_TEST_02 에서는 장애 조치 클러스터 관리자 실행 후, 클러스터에 연결을 선택한다.
AOT 의 IP 인 192.168.1.123 을 입력해서 클러스터 정보를 확인한다.
# 4
SQL 서버의 AlwaysOn 기능을 설정한다. AO_TEST_01 과 AO_TEST_02 에서 동일한 작업을 진행한다.
SQL Server 2016 구성 관리자 실행 후, SQL Server 서비스 트리 - SQL Server 속성을 확장한다.
AlwaysOn 고가용성 탭 선택 후, AlwaysOn 가용성 그룹 사용을 체크한다. 해당 작업은 SQL 서비스 재시작이 필요하다.
AO_TEST_01과 AO_TEST_02에서 SSMS 실행한다.
AO_TEST_01 에서 동기화를 진행 할 테스트 DB 와 테이블을 생성한다.
DB명 : gunnm
테이블명 : AO_Table_1
AO_TEST_01 에서 "새 가용성 그룹" 을 생성한다.
Always On 고가용성 - 가용성 그룹 - 우클릭 - 새 가용성 그룹 마법사 실행
가용성 그룹 이름에는 "AO_DB" 를 입력한다. 이것도 본인이 식별 가능하도록 생성하면 된다.
"데이터베이스 수준 상태 검색" 도 추가 체크해 주면 장애 조치 기능이 향상된다.
기존에는 가용성 그룹에 포함된 데이터베이스 중 하나가 오류 상태가 되어도 장애 조치가 실행되지 않았는데, SQL 2016 이상에서 "데이터베이스 수준 상태 검색" 을 체크하면 데이터베이스 수준의 장애에 대해서도 장애 조치가 진행된다.
가용성 그룹에 적용 될 DB 를 선택한다.
전제 조건으로 해당 DB 백업이 1회 필요하다. 이걸 하지 않으면 다음 단계로 넘어가지 않는다.
gunnm DB의 백업을 1회 진행하고 새로 고침 한다. 이제는 다음 단계로 넘어 갈 수 있다.
복제본 지정 단계로 진입되었으면, "복제본 추가" 를 선택해서 AO_TEST_02 를 추가 한다.
정상 진행시, 주 와 보조의 역할이 정해진다.
엔드포인트 탭을 보면, 미러링 구성때와 동일하게 기본 포트인 5022 를 사용하는 것을 확인 할 수 있다.
해당 포트도 사용자가 재구성 가능하지만, 지금은 테스트니까 기본으로 간다.
데이터 동기화 기본 설정은 "자동 시딩" 으로 체크한다.
보조 복제본에 자동으로 DB 를 생성하기 때문에 동기화 대상의 데이타 및 로그 파일 경로가 동일해야 함을 알 수 있다.
가용성 그룹 유효성 검사가 정상으로 체크되면 다음 단계로 진행 한다.
정상적으로 작업 완료 되면, 각 서버에서 아래와 같이 확인 할 수 있다.
* AO_TEST_01
* AO_TEST_02
# 5
이제 기본 설정 완료 했으니깐, 장애 조치 (Failover) 테스트를 진행한다.
장애 조치 클러스터 관리자 실행 후, 역할을 선택하면 "AO_DB" 가 추가 된 것을 확인 할 수 있다.
현 상태에서는, AO_TEST_01 이 소유권을 갖고 있다.
AO_TEST_01 의 IP 조회시, 아래와 같이 AO_DB 클러스터 IP 인 192.168.1.123 도 소유하고 있는 것을 볼 수 있다.
AO_TEST_01 의 SSMS 에서 테이블 추가를 해본다.
추가 테이블명 : AO_Table_2
장애 조치를 해봐야 하는데, 우선은 가장 나쁜 상황을 만들기 위해 AO_TEST_01 서버의 전원을 OFF 한다.
AO_TEST_02 의 장애 조치 클러스터 관리자에서 역할 부분 확인시, 소유자가 AO_TEST_02 로 변경 되었음을 알 수 있다.
AO_TEST_01 서버의 현재 상태는 "작동 중지" 이다.
AO_DB 클러스터 IP 인 192.168.1.123 도 AO_TEST_02 가 소유하고 있음을 알 수 있다.
이제 AO_TEST_02 의 SSMS 에 진입해서, DB 와 테이블, 가용성 그룹을 확인해 본다.
AO_TEST_01 이 주 였을 때는, AO_TEST_02 에서는 gunnm DB 에 대해서 어떠한 작업도 할 수가 없었으나,
주 와 보조의 역할이 변경 된 지금은 모든 작업이 가능하다.
AO_TEST_02 에서 테이블을 생성한다.
추가 테이블명 : AO_Table_3
AO_TEST_01 의 전원을 올리고 클러스터 및 DB 상태를 확인한다.
* 클러스터 상태
* DB 상태
# 6
장애 발생시 주 와 보조의 역할 변경을 확인했으니깐, 다시 역할을 복원하는 작업을 진행한다.
AO_TEST_02 의 SSMS 에서
Alwayson 고가용성 - 가용성 그룹 - AO_DB - 우클릭 - 장애 조치 선택 한다.
이 작업은 AO_TEST_01 에서 진행해도 무방하다. 효과는 같다.
프로그램에서 기본값으로 AO_TEST_01 을 새로운 주 복제본으로 선택하고 있다.
다음 단계에서 AO_TEST_01 서버 인스턴스에 연결한다.
작업에 대한 내용은 아래와 같이 요약 된다. 주 와 보조의 역할을 변경하고, 작업 중 데이터 손실이 없다는 뭐 그런 내용이다.
작업 결과는 아래와 같다.
각 서버의 SSMS 트리 확인시, 처음 구성 되었던 상태와 같이 주 와 보조 의 역할이 변경되어 있음을 알 수 있다.
클러스터 관리자에서도 소유자 변경을 확인 할 수 있다.
AO_DB 의 소유자는 변경 됐는데, 클러스터 IP 인 192.168.1.123 은 여전히 AO_TEST_02 가 소유하고 있다.
이를 통해서 확인 가능한 것은, 클러스터 IP 는 AD 구성의 DC 역할을 수행하는 것으로 볼 수 있다.
여기까지는 예전 SQL 미러링의 자동 장애 조치의 방식과 동일하다.
장애 발생시 주 와 보조 간 DB 데이타 동기화가 실시간으로 진행 되기 때문에 자료의 손실은 발생하지 않지만,
웹 서버의 DB 커넥션 부분을 수정하던가 주 와 보조 서버의 아이피를 변경해야 하는 불편함이 발생한다.
그래서 DB 커넥션을 위한 VIP 설정이 필요하다.
다음 글에서 가용성 그룹 수신기를 이용한 리스너 구성을 진행한다.
'Database > MS-SQL' 카테고리의 다른 글
| MSSQL 업그레이드 (1) | 2022.11.04 |
|---|---|
| AlwaysOn 가용성 그룹 구축 # 2 : Windows Server 2016 + MS SQL 2016 / None AD (1) | 2020.07.07 |
| SQL DB 암호화 / TDE(Transparent Data Encryption) (0) | 2018.12.07 |
| MS-SQL CPU 사용량이 높은 쿼리문 확인 (0) | 2018.06.22 |
| 현재 사용 중인 DB 중 제한 없는 DB 확인 쿼리 (0) | 2016.07.25 |
