모 고객사에서 아래와 같은 문의사항이 있었습니다.
# 기존 스크립트
1번 : sqlldr userid=scott/tiger control=abc.ctl errors=999999999
READSIZE=3145728 BINDSIZE=3145728 ROWS=5000
# 변경 스크립트
2번 : sqlldr userid=scott/tiger control=abc.ctl errors=999999999
READSIZE=20000000 BINDSIZE=20000000 ROWS=5000
# 문의사항
- rows 값을 5000을 주었는데 일정하게 commit이 되지 않는 현상 – 내부에서 테스트시 1번 스크립트로 돌렸을 때 commit이 4053 단위로 찍혔습니다. 그리고 2번으로 돌렸을 때는 5000으로 균일하게 commit이 되었는데 이는 READSIZE(buffer)에 따른 차이로 보입니다. READISZE는 MAX값이 20971520(20MB) 입니다.
- 레코드 길이에 따른 readsize,
bindsize의 적정사이즈 계산방법 – 적정사이즈 계산방법으로 ORACLE에서 권장하고 있는 방법은 없습니다. 현재 상황에서는 위에서 가이드한 READSIZE MAX값을 주고 테스트하고 부하가 많을 시 점차 값을 줄여나가는 방법으로 값을 찾아야 합니다. 그리고 READSIZE와 BINDSIZE 값은 같게 주는 것을 권장합니다.
SQL로더로 데이터를 넣을시에 잦은 commit은 밀어 넣는데에 속도가 느려지게 됩니다. 이를 줄이기 위해 ROWS를 5000을 주어 commit을 하게 했는데, 5000에 맞게 commit이 되지 않고 4053에 commit이 되고 있었습니다. 내부 테스트 결과 이는 READSIZE(buffer) 지정 값의 문제로 최대값을 주어 해결이 가능했습니다.
운영DB에 SQL로더를 이용하여 밀어넣는 경우에는. 서버의 Resource 사용율을 고려하고 최대한 부하를 적게하여 서비스에 영향이 가지 않게 해야되는 것이 포인트 입니다.
이는 실제 운영DB와 같은 환경에서 위 구문에서 사용하고 있는 수치를 정하기 위하여 많은 테스트를 해봐야 한다는 것 입니다.
아래는 SQL로더 사용시 성능 향상에 대한 방법입니다. 참고 하여 수행하시면 좋습니다.
– 제어파일과 데이터
파일을 분리하면 여러 로드 세션에서 제어 파일을 다시 사용 할 수 있다.
– 예상되는 데이터
볼륨을 기반으로 공간을 미리 할당하면 로드 시 확장 영역의 동적 할당을 방지하여 로드 속도가
향상된다.
– 테이블에 인덱스가
걸려있을 경우, 먼저 인덱스를 drop 시키고 SQL Loader 로 데이터를 올린 후 인덱스를 생성한다.
– 데이터의 양이 많을
경우 Redo log size 를 충분히 크게 설정한다. Redo log size 가 작을 경우 Redo log
switch 할 때 마다 LGWR 에서 timeout 이 발생하여 SQL Loader 에서 hang 현상이 발생 할 수 있다.
– 데이터를 로딩하기
전 데이터를 삭제 후 로딩하기 위해서는 REPLACE 옵션 대신 TRUNCATE 옵션을 사용한다.
REPLACE 옵션은 redo log 및 rollback 데이터가 발생하게 되지만 TRUNCATE 옵션은
그렇지 않다.
– Commit 문의
실행을 자주 하지 않을 경우 SQL Loader 가 보다 더 빨리 실행된다
– DIRECT PATH 옵션을 사용면 데이터가 DB Buffer Cache 을 거치지 않고 바로 데이터파일에 write 됨으로 속도가
빨라진다.
– PARALLERL
옵션을 사용한다. 다중 SQL Loader 세션을 사용할 경우 한 개의 테이블도 parallel 하게
loading 될 수 있다.