Oracle 과 MySQL 의 데이터 가 져 오기 가 왜 이렇게 차이 가 나 는 지
4358 단어 Oracle데이터 가 져 오기MySQL
나 는 주의 하지 않 았 던 이 문 제 를 생각 하기 시작 했다.
왜 Oracle 이 데 이 터 를 가 져 오 는 데 많은 문제 가 발생 합 니까?
우 리 는 이 문 제 를 정리 하고 내 보 내 는 방식 으로 이 야 기 를 나 누 었 다.
우선 Oracle 에서 내 보 낸 파일 형식 은 가 져 오 라 고 하지 않 았 습 니 다.내 보 내기 파일 은 dump 라 고 합 니 다.바 꾸 어 바 이 너 리 파일 임 을 이해 할 수 있 습 니 다.물론 실제 적 으로 이 파일 은 중요 한 정 보 를 캡 처 하 는 방법 이 많 습 니 다.예 를 들 어 Dump 머리의 정 보 는 strings 를 통 해 분석 할 수 있 습 니 다.저 는 심지어 몇 년 전에 비교적 까다 로 운 문제 에 부 딪 혔 습 니 다.DBA 는 직접 vim 에서 dump 파일 을 수정 하 는데 이 조작 위험 과 원가 가 비교적 높 습 니 다.
내 보 내기 에는 어떤 도구 가 있 습 니까?주로 exp,expdp 라 는 두 도구 가 있 습 니 다.expdp 의 내 보 내기 성능 은 상대 적 으로 시스템 자원 을 충분히 이용 하여 내 보 내 는 효율 이 높 습 니 다.exp 는 상대 적 으로 작은 표 에 있어 서 비교적 편리 합 니 다.expdp 의 내 보 내기 는 서버 모델 을 바탕 으로 하 는 것 입 니 다.즉,데이터 베이스 층 의 설정 을 해 야 합 니 다.이것 은 기술 문턱 을 증가 시 켰 습 니 다.
문제 가 있 는 지 모 르 겠 습 니 다.바로 Oracle 이 SQL*Loader 도 구 를 가 져 왔 지만 csv 를 간단 하고 효과적으로 내 보 내 는 도 구 를 제공 하지 않 았 습 니 다.내 보 낼 때 각 분야 의 영웅 들 이 각종 기 예 를 다 하고 데이터 사전 과 결합 하여 텍스트 여과 와 결합 하여 완성 한 셈 입 니 다.
MySQL 의 내 보 내기 방법 은 상대 적 으로 간단 하고 디자인 방향 이 재 미 있 습 니 다.내 보 낸 파일 은 바로 열 수 있 고 직접 수정 할 수 있 는 SQL 파일 입 니 다.이 디자인 은 많은 응용 장면 에서 정말 훌륭 해서 개발 학생 들 에 게 매우 우호 적 이다.
내 보 내기 도 구 는 원래 my sqldump 가 있 습 니 다.새로운 버 전 은 my sqlpump(전체적인 감각 가격 이 높 지 않 음)입 니 다.물론 my dumper 와 같은 보충 적 인 제3자 도구 도 있 습 니 다.
그래서 이 일 을 내 보 내 는 것 은 개발 학생 자체 에 문턱 이 있 고 격 행 이 산 과 같은 상황 에서 많은 학생 들 이 expdp 를 사용 하여 내 보 낼 때 안개 가 끼 었 다.안전성 을 보면 이 바 이 너 리 파일 은 오리지널 이 고 유연성 을 보면 MySQL 이 SQL 텍스트 를 바탕 으로 하 는 방식 이 비교적 편리 하 다.
내 보 낸 부분 은 사실 가장 중요 한 것 이 아니 라 장벽 이 생기 는 가장 큰 부분 은 가 져 온 부분 이자 문 제 를 가장 많이 제기 한 것 이다.
MySQL 에 어떤 데이터 가 져 오기 도구 가 있 는 지 이해 할 수 있 습 니 다.없 는 것 은 SQL 텍스트 입 니 다.원 하 는 대로 실행 하 셔 도 됩 니 다.도구 my sqldump 를 포함 하여 my sqlpump 에서 내 보 낸 파일 은 모두 이와 같 습 니 다.my dump 에 세트 로 된 my loader 는 작은 예외 라 고 할 수 있 습 니 다.
Oracle 가 져 오기 도구 가 있 습 니까?있 습 니 다.또한 세트 로 되 어 있 습 니 다.exp 는 imp 에 대응 하고 expdp 는 impdp 에 대응 합 니 다.
일반적인 데이터 가 져 오기 문 제 는 다음 과 같 습 니 다.
1)사용자 생 성 실패 알림,가 져 오기 실패
2)큐 시트 공간 이 존재 하지 않 습 니 다.가 져 오 는 데 실 패 했 습 니 다.
3)가 져 올 때 만 든 데이터 파일 공간 이 부족 하면 가 져 오 는 데 실 패 했 습 니 다.
4)가 져 올 사용자 권한 이 부족 하여 가 져 오 는 데 실 패 했 습 니 다.
그래서 저 는 dump 파일 을 가 져 오 려 고 합 니 다.exp 가 내 보 냈 다 면 분석 비용 이 낮은 편 입 니 다.
expdp 에서 내 보 낸 것 이 라면 많은 개발 자 들 이 어리둥절 한 표정 을 짓 는 다.
1)가 져 오 려 면 디 렉 터 리 를 입력 해 야 합 니 다.디 렉 터 리 가 무엇 입 니까?시스템 디 렉 터 리 가 아 닙 니까?
2)데이터베이스 사용자 가 이미 존재 한다 면 10 장의 표 가 존재 합 니 다.가 져 올 때 이 10 장의 표를 직접 무시 합 니 다.예 를 들 어 replace 나 truncate 등 추가 옵션 을 손 으로 삭제 하거나 선택 하지 않 는 한.
3)표 공간 소스 와 목표 엔 드 환경 이 일치 하지 않 습 니 다.어떤 표 공간 이 일치 하지 않 는 지 알 고 싶 으 면 dump 파일 을 분석 하 는 것 이 사실 편리 하지 않 습 니 다.고급 옵션 은 reap 입 니 다.tablespaces
4)데 이 터 를 가 져 온 후에 업무 학생 들 은 일부 표 가 방문 할 수 없고 좋 지 않 으 며 권한 을 재배 치 해 야 한 다 는 것 을 알 게 되 었 다.
일반적으로 dump 를 가 져 오 려 면 Oracle 측 에서 심각 한 일 입 니 다.디 렉 터 리 를 만들어 야 합 니 다.
create directory dump_data as '/data/dump_data';
grant read,write on directory dump_data to xxxx;
표 공간 저장,어떤 표 공간,어떤 표 공간 이 매 핑 되 어야 하 는 지 설정 합 니 다.데이터 가 져 오기 전에 이런 정 보 는 추출 하기 어렵 습 니 다.제 가 보통 사용 하 는 방식 은 미리 가 져 오 는 것 입 니 다.깨끗 한 환경 을 찾 은 다음 에 기본 옵션 을 가 져 오 는 것 입 니 다.어떤 표 공간 이 잘못 되 었 는 지,어떤 사용자 가 잘못 되 었 는 지,이 정 보 를 추출 한 다음 에 가 져 오 는 명령 을 다시 연결 하 는 것 입 니 다.
이 를 바탕 으로 나 는 관련 표 공간 과 데이터 파일 의 세부 사항 을 구축 하 러 간다.
데이터 파일 에 대해 저 는 자동 확장 방식 을 좋아 하지 않 고 미리 만 든 다음 에 자동 확장 을 추가 하 는 것 을 좋아 합 니 다.
마지막 으로 파일 가 져 오기
impdp system/xxxx directory=dump_data dumpfile=test.DMP logfile=impdp_test.log remap_tablespace=TEST_DATA1:DATA,TEST_DATA2:DATA,TEST_INDEX1:IDX,TEST_INDEX2:IDX
Oracle DBA 에 있어 서 이것 은 더 이상 정상 적 이지 않 은 일이 고 세심 하고 주도면밀 하 게 해 야 할 부분 이 많 지만 이런 과정 은 한 문외한 에 게 있어 원가 가 매우 높다.
항상 오 라 클 은 자동차 안의 BMW 처럼 조작 성 이 좋 고 전문 적 이 고 효과 적 인 관리 방식 을 많이 제공 한 다 는 느낌 이 든다.
한편,Oracle 의 역할 은 보통 백 GB 에서 시작 되 고 TB 상하 로 이러한 데이터 양 관 리 는 각종 도구 의 특징 과 특성 을 적당 하 게 배합 해 야 한다.저 는 이런 도구 들 이 더욱 효율 적 이 고 안전 을 추구 해 왔 다 고 생각 합 니 다.이런 측면 에서 Oracle 의 유지 관리 모델 은 전문가 가 완성 해 야 한 다 는 것 을 이해 할 수 있 습 니 다.
MySQL 의 관리 방식 은 인터넷 과 같은 변화 가 빠 르 고 데이터 양 이 상대 적 으로 적은 환경 에 적합 하 다.용이 성과 학습 문턱 이 편리 하 다 는 것 은 정말 극치 이다.예 를 들 어 특색 있 는 insert 문 구 를 여기저기 서 사용 해 야 한다(예 를 들 어 메 인 키 에 따라 순 서 를 매기 고 완전 열 명 을 표시 하 는 등).모두 my sqldump 를 통 해 쉽게 실현 할 수 있다.
이상 은 Oracle 과 MySQL 의 데이터 가 져 오기 가 왜 이렇게 차이 가 나 는 지 상세 한 내용 입 니 다.Oracle 과 MySQL 의 데이터 가 져 오기 에 관 한 자 료 는 다른 관련 글 을 주목 하 십시오!
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
Oracle 생성 향후 3일간의 전체 시점 (단계 상세)수요: X 좌표축 시간은 모두 정시 시간으로 앞으로 3일 동안의 예측을 보여준다(x 축은 앞으로 3일 동안의 정시 시간을 보여준다), 3시간마다 한 눈금, 가로 좌표는 모두 24개의 눈금을 보여준다 1단계: 현재 시...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.