정미나닷컴

기본 메커니즘 - Sort (양쪽 집합을 JOIN 컬럼 기준으로 정렬) → Merge (정렬된 양쪽 집합을 서로 Merge) SELECT /* ordered use_merge(d) */ E.EMP_NO, E.ENAME, D.DNAME FROM EMP E, DEPT D WHERE D.DEPT_NO = E.DEPT_NO; ▼begin for outer in (SELECT DEPT_NO, EMP_NO, RPAD(ENAME, 10) ENAME FROM SORTED_EMP) loop -- outer loop for inner in (SELECT DNAME FROM SORTED_DEPT WHERE DEPT_NO = outer.DEPT_NO) loop -- inner loop dbms_output.put_line(o..

기본 메커니즘 for(i=0; i= 1500 --- ④ORDER BY SAL DESC; Answer :: ② -> ③ -> ① -> ④ * pk_dept : dept.dept_no* dept_loc_idx : dept.loc* pk_emp : emp.emp_no* emp_deptno_idx : emp.dept_no* emp_sal_idx : emp.sal Execution Plan ------------------------------------------------------------------------------0 SELECT STATEMENT1 0 SORT ORDER BY2 1 NESTED LOOPS3 2 TABLE ACCESS BY INDEX ROWID DEPT4 3 IND..

Index Range Scan - B*Tree 인덱스의 가장 일반적이고 정상적인 형태의 액세스 방식(수직적 탐색 후 필요한 범위만 수평적 탐색) - 항상 빠른 속도를 보장하진 않음 - 인덱스 스캔 범위를 얼만큼 줄일 수 있느냐, 테이블 액세스 횟수를 얼만큼 줄일 수 있느냐가 관건 => 인덱스 설계와 SQL 튜닝의 핵심 원리 - 인덱스를 구성하는 선두 컬럼이 조건절에 사용되어야 함 Index Full Scan - 수직적 탐색없이 인덱스 리프 블록을 처음부터 끝까지 수평적으로 탐색하는 방식 - 최적의 인덱스가 없을 때 차선책(인덱스 선두 컬럼이 조건절에 없을 경우) - 최종 결과값이 적을때 Table Full Scan보다 Index Full Scan이 훨씬 효율적 Index Unique Scan - 수직적 ..

쿼리의 조건절에 인덱스 선두 컬럼이 사용된 경우(인덱스가 B*Tree 형태일 때)옵티마이저는 인덱스의 Root부터 탐색을 시작해 Branch를 거쳐 원하는 레코드 키값이 존재하는 Leaf 까지 도달한다. 이 때 Root -> Branch -> Leaf 에 도달하는 과정(Leaf node의 시작점을 찾는 과정)을 수직적 탐색,Leaf node의 시작점에서부터 원하는 범위까지를 scan하는 과정(인덱스는 정렬 상태이므로)을 수평적 탐색,수평적 탐색을 통해 get한 RowID를 이용해 궁극적으로 원하는 데이터가 있는(Select 절에 명시된 컬럼 데이터) 테이블까지 도달하는 과정을 Table Random Access라고 한다. 하지만 주의해야 할 점은 조건절에 인덱스 컬럼을 사용한다고 해서 무조건 인덱스 활용..

B*Tree Index (B: Balanced)- 인덱스 Root에서 Leaf Block까지 어떤 값으로 탐색하더라도 읽는 Block 수가 동일 (Root로 부터 모든 Leaf Block 까지의 높이가 동일) 위 그림을 보면서 처음에 Root Block과 Branch Block에 있는 KEY 값 때문에 헷갈렸는데 저기에 나타난 KI나 BER, FO, JONES 등등의 값은 테이블 레코드 값이라기 보다는 범위를 의미한다. 다시 말해 KI는 > KI 를 의미하고 BER는 > BER 를 의미한다. Root Block & Branch Block - 저장 엔트리: {KEY:DBA(하위 노드의 Data Block Address)} * 여기에 저장된 KEY 값은 테이블 레코드의 KEY 값이 아닌 하위 노드의 범위를 ..

ORA-06502: PL/SQL: 수치 또는 값 오류: 문자열 버퍼가 너무 작습니다 : 오라클 Function이나 Procedure 내에 선언된 변수의 크기보다 더 큰 값을 담으려고 할 때 발생하는 에러 하지만 내가 문자열을 담으려던 변수는 Function 내에 VARCHAR2(32767)로 선언되어 있었고 아무리 DB를 뒤져봐도 32767 byte를 넘어가는 데이터는 없어서 멘붕이 오던 찰나, 오라클 VARCHAR2는 4000 byte까지만 지원된다는 구글님의 조언을 얼핏 듣고 그렇다면 저 변수는 왜 32767 byte로 선언되어 있는가 의문이 들어 다시 한번 폭풍 검색- 결론은 PL/SQL내에서는 VARCHAR2가 32K까지 지원이 되지만 어차피 그 변수값을 테이블이나 뷰에 담을거라면 4000 byt..

String sDate = "20161026"; SimpleDateFormat sdFormat = new SimpleDateFormat("yyyyMMdd"); // sDate와 형식이 맞아야 함 Date date = transFormat.parsesDate; // String -> Date 전환 Calendar tmpDate = Calendar.getInstance(); tmpDate.setTime(date); // Date -> Calendar 전환 tmpDate.add(Calendar.DATE, -3); // 3일전 계산 SimpleDateFormat transFormat2 = new SimpleDateFormat("yyyy년 MM월 dd일"); // 원하는 출력 형식 System.out.printl..

- SYNONYM 조회 SELECT * FROM USER_SYNONYMS WHERE TABLE_OWNER='소유계정'; - SYNONYM 생성 CREATE SYNONYM 소유계정.테이블명(or 프로시저명) FOR 부여계정.테이블명(or 프로시저명); - SYNONYM 삭제 DROP SYNONYM 시노님명; * 프로시저 실행 권한 부여 GRANT EXECUTE ON 소유계정.프로시저명 TO 부여계정;