하지 말 것 목록
- 사용자로부터 문자열 리터럴을 입력받아 SQL을 만들지 말 것. (eg: 항상 바인드 변수를 사용할 것)
- 데이터가 없는 상태 또는 실제 시스템의 극히 일부 데이터만 있는 상태에서 테스트하지 말 것. 실제 시스템의 통계 정보를 불러들이는 것도 소용 없음. 실제로 어떻게 되는지를 보려면 실제 만큼의 데이터가 필요함.
Posts
DBMS_RANDOM 패키지 사용법
랜덤한 숫자나 문자열을 만들 때 DBMS_RANDOM 패키지를 사용하면 된다.
set timing을 이용한 SQL 실행 속도 측정법
SQL*Plus에서 실행시킨 SQL 또는 PL/SQL 블록의 실행속도를 보려면 다음과 같이 set timing on을 사용하면 된다.
TIMESTAMP 컬럼으로 파티션 하는 방법
일반적으로 range 파티션 테이블을 만들 때는 다음과 같이 한다.
날짜 데이터 저장
DBMS마다 날짜와 시간을 저장할 수 있는 데이터 타입을 제공한다. 그러나 날짜와 시간을 저장하는 데 'YYYYMMDD', 'HH24MISS' 형식의 문자열을 사용하는 경우도 많다. 인터넷 문서나 오래된 책을 찾아보면 날짜를 저장할 때 DATE 타입을 사용하지 말고 문자열로 저장하는 것이 좋다고 주장하는 경우도 흔하게 볼 수 있다. 날짜나 시간 데이터를 저장하는 데 문자열 데이터 타입을 사용하면 불필요하게 저장 공간이 늘어날 뿐 아니라 데이터 정합성이 떨어지고 성능에까지 영향을 미칠 수 있다. 이에 대해서 하나씩 살펴보자
올바른 데이터 타입 사용하기
데이터베이스에 테이블을 만들 때 각 컬럼의 데이터 타입을 정하는 것은 무척 쉬워 보인다. 데이터베이스에서 기본으로 제공하는 데이터 타입 종류가 엄청나게 많은 것도 아니고, 테이블에 저장할 데이터란 것도 대부분의 경우는 뻔하기 때문이다. 그러나 실제 데이터베이스를 보면 데이터 타입이 잘못 지정된 컬럼을 매우 자주 볼 수 있으며, 신규 테이블 생성을 요청할 때나 또는 컬럼 추가를 요청할 때도 데이터 타입을 잘못 지정해 요청하는 경우가 많다.
Direct-path Insert시 주의사항
뭔가에 대해 어설프게 아는 것은 큰 위험을 초래할 수 있다. 이번에는 Direct-path Insert에 대한 어설픈 지식으로 큰 사고를 낼 뻔 했다. 지금까지 알고 있었던 사실은 Direct-path Insert를 이용하면 redo와 undo 로깅을 생략해 성능을 향상시킬 수 있다는 것이었다. 따라서 테이블에 대량의 데이터를 넣을 때 이 방법을 활용하곤 했다.
다이렉트 로드와 인덱스
대량 데이터를 로드할 때 항상 궁금했던 것이 있다. 다음 두 가지 방법 중 어떤 것이 빠를까 하는 것이다.
- 방법1: 인덱스가 있는 상태에서 그냥 다이렉트 모드로 로드
- 방법2: 인덱스를 날리고 로드한 다음 인덱스를 생성
컬럼 추가와 디폴트 값
기존 테이블에 컬럼을 추가할 때 디폴트 값을 지정하면 기존 데이터는 건드리지 않고 새로 추가되는 데이터에 대해서만 디폴드 값이 적용되는 줄 알고 있었다. 그런데 작업을 하다가 그동안 잘못 알고 있었다는 것을 알게 되었다. 다음 두 작업은 완전히 다르게 진행된다.
MINIMIZE RECORDS_PER_BLOCK
SQL Reference에 보면 records_per_block절에 대해 다음과 같이 설명되어 있다.
instruct Oracle Database to calculate the largest number of records in any block in the table and to limit future inserts so that no block can contain more than that number of records.