aDBanced Team

[테스트 환경] - Windows Server 2008 64bit - Oracle 11g 64bit standard 1. 문제 상황 - 시퀀스를 사용해서 INSERT ALL로 부모 테이블과 자식 테이블에 데이터를 적재한다. 1.1. 테이블 생성 스크립트 -- 부모테이블 CREATE TABLE ADB_PARENTS ( PR_SEQNO NUMBER(9) NOT NULL, PARENTS_NM VARCHAR2(50) NULL ); ALTER TABLE ADB_PARENTS ADD CONSTRAINT PK_ADB_PARENTS1 PRIMARY KEY ( PR_SEQNO ); -- 자식테이블 CREATE TABLE ADB_CHILD ( PR_SEQNO NUMBER(9) NOT NULL, CHILD_NM VARCHA..

1. 문제 발생 - DB 오픈 시 UNDO 데이터 파일 에러 발생 SQL> startup ORACLE instance started. Total System Global Area 422670336 bytes Fixed Size 1344616 bytes Variable Size 314575768 bytes Database Buffers 100663296 bytes Redo Buffers 6086656 bytes Database mounted. ORA-01157: cannot identify/lock data file 3 - see DBWR trace file ORA-01110: data file 3: '/app/oracle/oradata/testdb/undotbs01.dbf' 2. 문제 해결 -- UNDO..

1. 문제 발생 - Alert.log에 다음과 같은 에러 발생 ORA-00600: internal error code, arguments: [4193], [], [], [], [], [], [], [], [], [], [], [] 2. 문제 확인 - Alert.log에 적힌 trace파일을(예. [SID]_smon_3124_ORA_00600.trc) 확인하면 REDO의 seq와 UNDO의 seq가 다른 것을 확인할 수 있음. - 주로 정상적으로 Oracle이 종료되지 않았을 때 발생함. Error 600 in redo application callback Dump of change vector: TYP:0 CLS:26 AFN:3 DBA:0x00c021c0 OBJ:4294967295 SCN:0x0001.e..

[테스트 환경] OS : windows server 2008 DB : ORACLE 11gR2 오라클 데이터 파일(Data file)은 데이터가 적재 될수록 크기가 점점 늘어나며, 데이터를 삭제 또는 테이블을 DROP 한다고해서 크기가 줄어 들지 않는다. 따라서 데이터 파일의 현재 사용량을 계산하고 RESIZE작업을 해야만 데이터 파일 크기를 변경 할수 있다. SQL을 통하여 현재 데이터 파일의 사용량을 확인하고, 축소 가능한 데이터 파일 용량을 계산하여 최종 변경하는 출력하는 작업을 진행 한다. 1 .현재 데이터 파일 사용량 확인 - 테이블 스페이스 명으로 조회하여 몇 개의 데이터 파일로 구성된 개수와 데이터 파일의 크기 및 사용량을 확인 한다. [조회 쿼리] SELECT SUBSTR(A.TABLESPA..

# 컨트롤파일 경로 변경 /*1. 파라미터 파일 확인 2. 컨트롤파일 경로 확인 3. DB 종료 4. 컨트롤파일 복사 5. 컨트롤파일 경로 변경 6. 컨트롤파일 경로 변경 확인 */ -- 1. 파라미터 파일 확인show parameter spfile; -- 2. 컨트롤파일 경로 확인 SELECT A.NAME FROM V$CONTROLFILE A; -- 3. DB 종료 shutdown immediate; -- 4. 컨트롤파일 복사 -- 기존 컨트롤파일을 대상 디렉토리로 복사 -- 5. 컨트롤파일 경로 변경 -- 5.1. mount로 시작 startup mount; -- 5.2. controlfile 경로 변경 alter system set control_files ='경로','경로' scope=spfile..

1. SHRINK 작업의 정의 - SEGMENT에 할당된 EXTENT를 TABLESPACE로 반환하는 작업 - SHRINK 작업으로 SEGMENT의 용량은 줄어들고, TABLESPACE의 용량은 줄어들지 않음(TABLESPACE의 용량은 축소시키기 위해서는 RESIZE 작업이 필요함) - 장점: INSERT,DELETE를 통해 데이터를 이동하기 때문에 추가적인 공간이 필요하지 않음 - 단점: 일부 데이터만 이동하기 때문에 Row Migration이나 Chaining이 전체적으로 해결되지 않음 2. SHRINK 작업 방법 (출처: http://www.slideshare.net/ashilo/getting-to-know-oracle-database-objects-iot-mviews-clusters-and-mo..

Parse Call을 제외하고 SQL 수행 중에 발생하는 Execute Call, Fetch Call을 줄이는 방법에 대해 설명하고, 데이터베이스 Call을 User Call과 Recursive Call로 나누어 각각을 최소화하는 원리와 방안에 대해서 설명 합니다. Call 통계select * from emp; call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 1 0.01 0.03 0 0 0 0 Execute 1 0.00 0.01 0 0 0 0 Fetch 2 0.00 0.00 0 8 0 14 ------- ------ -..

Cardinality는 집합 안의 원소 개수, 오라클의 경우는 예측 Row 수라고 할 수 있습니다. 옵티마이저가 실행계획을 세우는 데 있어서 가장 중요한 것은 정확한 Cardinality의 계산이며, 동시에 그것은 실행계획이 비효율적인 가장 큰 원인이기도 합니다. 아래 실습은 기본적인 테이블을 생성 후에 ANALYZE TABLE을 하면 통계정보가 생성되며, 이후 Cardinality를 확인하는 방법과 Histogram에 따라서 정확한 값을 예측 불가능 하다는 것을 확인해보도록 하겠습니다. 즉, Histogram을 사용하지 않도록 설정합니다. Cardinality의 기본적인 개념을 먼저 파악하겠습니다. 1. Base Cardinality Base Cardinality란 Table의 전체 Row 수를 의미합..

1. 바인드 변수의 부작용과 해법1.1. 바인드 변수 사용 시 - 최초 수행 시 : 최적화를 거친 실행계획을 캐시에 적재(하드 파싱) - 실행 시점 : 캐시의 실행계획을 그대로 가져와 값을 다르게 바인딩하면서 반복 재사용(소프트파싱) - 바인딩 시점 (최적화 이후인 실행시점) - SQL 최적화 시점에 조건절 컬럼의 데이터 분포도(컬럼 히스토그램) 활용을 못함(부작용) - 옵티마이저는 평균 분포를 가정한 실행계획을 생성 - 컬럼의 데이터 분포가 균일 시 문제가 없음, 그렇지 않을 시 시행 시점에 바인딩 되는 값에 따라 최적이 아닌 실행계획 수행가능(부작용) - 등치(=) 조건이 아닌 부등호나 범위기반 검색 조건 시 고정 된 규칙을 사용하여 더 부정확한 예측의 실행계획 생성가능(부작용) 1.2 바인딩 변수 ..

특정 테이블스페이스 Hot backup 시에는 해당 데이터 파일을 사용하지 못함 따라서 backup 도중 테이블스페이스에 속한 테이블의 데이터 변경이 발생할 경우, SCN을 통해서 변경된 데이터에 대한 작업 확인 1. BEGIN BACKUP - BEGIN BACKUP은 버퍼 캐시에 있는 데이터가 데이터 파일로 내려 써진 이후에 진행된다. 2. 현재 SCN 확인 - 쿼리SELECT CURRENT_SCN FROM V$DATABASE; 3. 데이터파일의 SCN 확인 - 쿼리SELECT A.NAME, B.CHECKPOINT_CHANGE#FROM V$TABLESPACE A,V$DATAFILE BWHERE 1 = 1AND A.NAME = 'TEST_TBS' /*테이블스페이스명*/AND B.TS# = A.TS#; 4..