복구하려는 DB가 사용될 환경
현재 thirdparty 프로그램의 구조는
- 클라이언트(윈도우)
- 서버(리눅스 게임서버같은 역할)
- netdaemon(리눅스 서버 열기전 구동)
- myname이라는 전체 데이터 테이블,
- myname의 데이터와 클라이언트딴에 있는 데이터를 함께 새로이 저장하는 테이블들
이런 상황.
내가 가진 건 db1.dmp, db2.dmp 이거 두 개랑 서버 소스 코드 뿐이라서 서버 소스 코드를 좀 분석해야했다.
startgame 이런 함수안에 분명 하드코딩해놨을거같아서 검색어 계속 다르게해가면서 찾아봤다. 역시 인텔리센스가 조아
메인 DB 이름, 계정명, 비밀번호, 권한을 어디까지 줘야 하는지 정도는 분석이 된 상태이다.
클라이언트딴에서 실행하는 db와 관련된 주요 기능 두 개를 A,B라고 하면
A, B 두 기능을 윈도우에서 수행하여 디버깅 아닌 디버깅을(도커환경같은거 없고 리눅스에서 makefile로 빌드하는 형식이라서 시간 상 그냥 이것저것 해보고 출력을 확인해보는게 최선이였다.) 열심히 해본 결과
윈도우에서 A. 기능을 수행하면 리눅스에서 새로운 oracle user와 같은 이름의 테이블을 만들고, user의 default_tablespace를 해당 테이블로 지정한다.
윈도우에서 B. 기능을 수행하면 리눅스에서 A. 기능을 수행할때 생성된 table을 불러와 수정하고 다시 저장한다.
까지 분석이 되어있는 상태이다.
이제 db 복구 시~작!
tablespace 확인
myname 이라는 user의 username과 tablespace를 확인하는 코드,
이걸로 구버전 oracle에서 생성된 user의 tablespace까지 지정해준다는 것을 알게 되었다.
select username, default_tablespace, temporary_tablespace from dba_users where username = 'myname';
이제 내가 할일은 드디어 dmp 파일을 imp 하는 것
rcb21 데이터베이스는 rcb21 유저가 관리하고 비밀번호도 소스코드에 하드코딩되어있다.
현재 db 이름 확인하는 방법
SELECT NAME FROM v$database;
imp 명령어 사용 중 자꾸 sysdba 비밀번호가 틀리다고함..
sysdba 계정으로 로그인하여 비밀번호가 맞는지 확인하고싶다면 아래와 같이 sys as sysdba로 로그인 시도 해야지 sysdba나 sys 이렇겐 안된다.
sysdba 계정 비밀번호 알고있는게 맞는지 확인하기
sqlplus
>>> Enter user-name : sys as sysdba
user 테이블에 권한이 없다?
sysdba 계정으로 imp를 시도하는 동안 users 테이블을 건들 권한이 없다고하길래
sysdba한테 user 테이블 수정 권한이 없는게 말이 되나 싶었는데, 아래 코드 실행후 다시 imp해보니까 오류 안나고 잘 된다.
user 테이블에 대한 무제한 수정권한 주기
alter user sysdba quota unlimited on users;
위를 바탕으로 새로 생성한 user에게
grant sysdba to myuser;
grant connect, resource, dba to myuser;
alter user myuser quota unlimited on users;
여기서 실수가 발생하는데, 실장님께서 지나가면서 imp말고도 impdp라는 명령이 있으니 알아보고 해봐라~ 라고 하셨다.
oracle에서 db를 복구하는 방법은 imp와 impdp 두가지가 있다.
imp 유틸리티의 단점을 개선하기위해 생긴게 impdp 유틸리티인데,
지금 생각해보면 명령어 이름에서 부터
exp한 dmp파일은 imp로,
expdp한 dmp파일은 impdp로 복구해야할 것만 같지만
당시엔 마음이 급해서 일단 더 빠르다길래 impdp로 시도해보기로 했다.
결과적으로는 해당 dmp파일이 expdp명령으로 백업한 dmp파일이 아닌 exp해서 생긴 original dump file이라는 ORA-39143 오류와 함께 imp 명령을 사용하는 방향으로 돌아와야 했다.
impdp 하려고 dumpdir 설정했던 삽질(본문의 목적과 관계없음)
내 dmp 파일의 위치 알아내기
내 dmp 파일의 위치를 찾기위해 (대충 어디 근처인지는 앎)
cd ../ cd 폴더이름 ls 를 아주 반복하면서 찾아다닌 결과 찾았다!.
pwd 명령어로 현재 디렉토리를 알아내서 이를 DUMPDIR로 설정해야 impdp 명령어를 사용할 수 있다.
내가 찾아낸 , dmp파일이 위치한 디렉토리는 ‘/home/ora19c/’ 이다.
DUMPDIR을 다음과같이 설정한다. 오라클인스턴스를 실행한 다음 가능함!
create or replace directory DUMPDIR as '/home/ora19c/';
grant read, write on directory DUMPDIR to impdp를 실행할 유저;
디렉토리를 잘 생성(변경)했는지는 다음과같이 확인해 볼 수 있다.
select * from all_directories where directory_name = 'DUMPDIR';
위에서 DUMPDIR로 생성(변경)했으니까 지금도 DUMPDIR로 검색해야겠지?
어차피 impdp 못하니까 imp로 돌아가자..
object 중복 생성 오류
또 imp로 복구를 여러번 시도하다보니까
첫 시도에, 오류로인해 dmp파일 안 빈 테이블들을 모조리 가져왔는데, 두 번째 시도에 또 가져오려고하니까 해당 object가 이미 생성되었다는 ora-00955 오류가 발생한다.,
→ imp parameter 중 ignore=y를 활용하면 됨
ora-01917 : user or role ‘*’ does not exist
이제 어느정도 table들을 다 잘 생성되는데 dmp imp하는 과정에서 입력된 명령어인
“GRANT SELECT ON “어떤 테이블” TO “PARA_ROLE” 이라는 오류가 발생했다.
다행히 user인지 role인지는 grant하는 대상의 이름이 PARA_ROLE이라서 role인지는 알겠는데,
ROLE에게 권한부여하는 부분에서 오류가 생겼으니까 CREATE ROLE을 못했거나 안했거나 하는 문제일것, 근데
오류 전문을 살펴봐도 CREATE ROLE 명령어를 실행한 기록은 없었다.
그래서 sysdba계정으로 Role 만들고 다시 실행해보기
create role PARA_ROLE;
core dump / segmentation fault
보통 테이블 저장시에 발생하는 오류인데, 원인은 다행히도 쉽게 찾았다.
오라클은 데이터를 저장할때 character set으로 저장하는데,
내가 imp할 db의 캐릭터셋과 일치되도록 parameter를 조정하여 imp해야한다.
그래서 현재 db의 캐릭터셋을 확인하는 법은?
select value from nls_database_parameters where parameter='NLS_CHARACTERSET';
그래서 캐릭터셋을 맞추고나면 잘 실행되는지 알아보려고하는 찰나~
출장갔던 실장님이 돌아오시면서 db설치하자마자 실행할 sql 스크립트 파일이 3개나 있었다는것을 말씀해주셨다.
ㅋㅋ
보안상 스크립트 전체를 올리진 못하니까 요약하자면,
내가 생성한 user를 생성, 권한 주는 구문, procedure(user 생성, 권한 주기, tablespace 지정 등) ,
Role 생성 및 권한 주는 구문 등이 있었다.
다행히도 삽질의 결과로 했던 role 생성이나 user id, pwd 적절하게 생성한것이 날 뿌듯하게하긴 했다.
안빼먹고 알려줬었으면 하루 아꼈을텐데,,
덕분에 3일정도지만 oracle 환경설정도 만져봤으니 참는다..
여기까지가 삽질 1부
