E-컨테이너 오라클 dbms 설치
개요
B-시험장에 몰래 가져갈 이경오의 SQL + SQLD 비밀노트에서 공부하며 실습한 내용을 정리한다.
- 오라클 DBMS 설치
- 리스너가 제대로 열렸는지 확인
- DBMS 도구 설치 후 연동
- sqlplus
위의 내용들을 목표로 한다.
컨테이너를 사용하는 이유는 내가 항상 쓰는 노트북을 실습용으로 사용하기에 그렇다.
유사시에 빠르게 지우고, 빠르게 킬 수 있는 데이터베이스를 확보하고 싶었다.
대신 그만큼 영속성을 위한 설정을 해야 한다는 것도 유의해야 한다.
오라클 디비 컨테이너 탐색
https://www.oracle.com/kr/database/technologies/oracle-database-software-downloads.html
해당 페이지에서는 컨테이너로 다운 받을 수 있는 디비에 대해 말해주고 있다.
docker pull container-registry.oracle.com/database/free:latest
https://velog.io/@hoplin/Docker로-Oracle-DB사용하기
https://yooloo.tistory.com/27
아직 아는 게 많지 않아서 이 정도로만 만들었다.
컨테이너 내부 분석
내부에 들어가보니 이러한 파일이 존재한다.
초기 비밀번호 세팅을 어떻게 할 수 있는지에 대한 간략한 유추가 가능하다.
lsnrctl status를 쳤을 때 명령어가 제대로 동작했다면 성공한 것이다.
이것으로 DBMS와 통신할 수 있는 리스너가 열려 있다는 것을 확인할 수 있다.
실행법 참조
docker run --name <container name> \
-p <host port>:1521 \
-e ORACLE_PWD=<your database passwords> \
-e ORACLE_CHARACTERSET=<your character set> \
-e ENABLE_ARCHIVELOG=true \
-e ENABLE_FORCE_LOGGING=true \
-v [<host mount point>:]/opt/oracle/oradata \
container-registry.oracle.com/database/free:latest
이 중 패스워드를 입력하지 않으면, 패스워드는 랜덤으로 생성된다.
위에서 보았듯이 컨테이너가 실행되고 나서 패스워드를 바꾸는 것도 가능하다.
문서에서는 컨테이너 생성 시점에 환경변수로 비밀번호가 남기에 후자의 방법을 권고한다.
docker exec <oracle-db> ./setPassword.sh <your_password>
참고로 도커 명령어로 바꾸는 건 내가 하고 있는 것이고, 원래는 Podman 명령어로 쓰여져 있다.
글쎄, 근데 원하는 대로 작업이 이뤄지지 않고 있다.
일단 문자열 세트를 잘못 지정한 것 같다.
그리고 지네가 하라고 한 명령어 실행하는데 sqlplus가 없다는 건 무슨 뚱딴지 같은 소리인가?
내가 커스텀한 스크립트도 아닌데.
이 문제를 해결하기 위해 위의 이슈들을 해결해야 하는 줄 알고 계속 손을 댔다.
오라클 홈과 베이스 환경변수를 세팅하고, 비밀번호를 새로 세팅하고.
그러나 다시 보니, 이건 결국 볼륨 마운트하는 디렉토리에 권한이 없어서 쓰는 게 안되는 문제인 것으로 보인다.
빙고.
세팅이 완료되자 디렉토리에는 이러한 내용이 들어갔다.
제대로 만들어지기만 하면 세팅도 문제 없이 가능하다.
DBMS 도구 설치
sqlplus 설치 및 사용
먼저 sqlplus를 사용해보려 했는데, 대부분의 글들을 보니 디비 서버를 설치할 때 같이 다운 받는 것으로 이야기한다.
하지만 또 이것도 먼저 만들어진 이미지는 항상 존재하기 마련.
https://github.com/oracle/docker-images/tree/main/OracleInstantClient
여기에 있는 도커파일을 다운 받고, 빌드를 해서 해당 이미지로 접속을 시도해본다.
오케이 설치는 되었다.
DB 컨테이너 내부에서는 동작되는 게 확인된다.
그러나, 1521이라는 포트 번호를 명시하면 계속 연결이 이뤄지지 않았는데 아무래도 이게 원인인 것 같다.
왜 임의 포트가 개방되어 있을까?
문서에서는 명확하게 1521이 기본이라고 쓰여져 있는데 말이다.
일단 여기에서 정답은 44313이었다.
일단 귀찮은 구석들은 자동화시켰다.
책에서는 다음의 세 가지 명령어를 입력하여 추가 세팅을 하라고 하는데, 이거 마운팅된 부분에 저장되는 정보인 것일까?
select문을 실행해봤으나, 위에 떠있는 ORA-01012 에러가 계속 발생하고 있다.
검색해보기로는 세션이 끊어진 상태에서 명령어를 치면 나타난다고 한다.
나와 비슷한 사례를 겪는 사람이 많이 없는 모양이다.
이걸 어떻게 해야 하나, 난감하다.
그런데 또 이런 것들은 되기는 한다.
어쩌면 잘못된 쿼리를 날린 것에 대한 반응일지도 모르겠다.
하지만 직접 db 컨테이너에 들어가서 확인해봤을 때는 문제없이 작동했다.
연결 상에 어떤 이슈가 있는 것이 틀림 없다.
https://blog.naver.com/sppp111/130096542181
여기에서는 리스너의 문제도 확인해보라는 것 같다.
분명 어떤 문제가 발생하고는 있다.
리스너에 대한 설정 파일은 여기에 있다.
5450260bdc1e 같은 건, 보통 컨테이너의 해시값이다.
그런데 현재 떠 있는 컨테이너에 이런 게 없는 걸 보니, 볼륨 마운팅된 맨 처음 컨테이너의 값이 적힌 것이 분명하다.
아예 ip 번호로 바꿔본다.
여기를 직접적으로 수정하면 바로바로 수정된 사항이 반영되는 듯하다.
그러나 아직까지 뭐가 뭔지 명확하게는 모르겠다.
파일을 싹 지우고 새로 파보니, 역시나 이번에는 제대로 띄워진 게 확인된다.
하 씨.. 바로 되는 거 보소.
그러니까 잠시 정리하자면, 컨테이너가 휘발될 것이 걱정되면 볼륨 마운팅을 하라고 해서 했는데, 기껏 해봤자 다시 컨테이너를 띄울 때는 해당 정보들을 제대로 참조하지 않기 때문에 문제가 발생한다;;
즉, 볼륨 마운팅을 해도 컨테이너를 없앴다가 다시 가동할 때 새로운 프로세스가 기존의 파일 정보를 확인한 후 다른 db 프로세스가 있다고 생각하고 임시 포트로 프로세스를 만드는 상황이라는 것이다.
이에 대한 해결책은, 컨테이너를 하나 만들었다면 이를 지우지 않고 사용하는 것이다.
최소한 파일이 남아있기에 영속성을 당장은 보장이 가능하다.
다만 정말 완벽한 방향은 역시 컨테이너가 지워졌다 다시 생겨도 파일 정보를 읽고 정확하게 dbms가 가동되는 것이라고 생각한다.