알파돈

LIKE 조건과 BETWEEN 조건중 어느것이 더 성능이 좋을까? 정답은 바로 BETWEEN 조건이다. 아래와 같은 SQL을 작성했다고 해보자 SELECT /*LIKE 조건을 이용한 검색*/ * FROM 매출 WHERE 기간 LIKE '2024%' SELECT /*BETWEEN 조건을 사용한 검색*/ * FROM 매출 WHERE 기간 BETWEEN '202401' AND '202412' 기간으로 생성된 인덱스가 있다는 과정에 두 쿼리를 실행하면 두 SQL 모두 범위검색 (RANGE SCAN)을 실행 할 것이다. 이러면 두 SQL의 성능에는 큰 차이가 없을것이다. 하지만 아래의 쿼리 부터는 말이 달라진다. SELECT /*LIKE 조건을 이용한 검색*/ * FROM 매출 WHERE 기간 LIKE '2024..

SQL의 처리과정은 아래와 같다 SQL 작성을 하면 SQL Parser 은 SQL 파싱을 진행 한다. 옵티마이저가 SQL 최적화를 진행 한다. Row-Source Generation가 옵티마이저에게 전달받은 최적을 실행 계획을 받아 코드 또는 프로시저 형태로 포맷팅 실행 SQL Parser 개발자가 작성한 SQL을 이루는 구성요소를 분석하고 파싱 트리를 만든다. Syntax 체크 : 문법 검사 Symantic 체크 : 오브젝트의 참조 및 존재 여부 검사 Shared Pool에 캐싱되어 있는 SQL 커서인지 확인 : 해시 알고리즘 사용 SQL Optimizer Query Transformer : SQL을 최적화 하기 쉬운 형태로 변환 Plan Genrator : SQL 실행 계획을 생성 Estimarot ..

옵티마이저(optimizer) 개발자를 대신해서 프로그래밍 해주는 DBMS에서의 프로그래머 같은 존재이다 즉 개발자가 SQL을 작성시 옵티마이저는 최적의 실행계획(현재 비용기반 옵티마이저를 대부분 사용하고 있다.)을 세우고 프로시저를 생성해준다 사용자 -> SQL 작성 -> 옵티마이저 -> 실행계획 선택 -> 프로시저 생성 사용자가 아래의 SQL을 작성 했다 가정해보자 SELECT * FROM EMP E WHERE E.EMPNO = 9999 옵티마이저 EMP라는 테이블에서 EMPNO가 9999인 데이터를 찾기 위해서 실행계획을 찾아낸다. 데이터 딕셔너리(Data Dictionary)에서 미리 수집해 놓은 정보들을 바탕으로 실행 계획의 예상비용을 산정한다. 가장 적은 비용의 실행계획을 선택 즉, 옵티마이저..

1. 옵티마이저 - SQL을 가장 빠르고 효율적으로 수행할수 있도록 최적의 처리 경로를 생성해주는 DBMS 엔진

ora-00000 성공적인 정상 종료입니다. ora-00001 유일성 제약조건(%s.%s)에 위배됩니다. ora-00017 트레이스 이벤트 설정이 세션에 요구되었습니다. ora-00018 최대 세션 수를 초과했습니다. ora-00019 최대 세션 라이선스 수를 초과했습니다. ora-00020 최대 프로세스 수(%s)를 초과했습니다. ora-00021 세션이 다른 프로세스에 첨부되어 있음; 세션을 변경할 수 없습니다. ora-00022 부적절한 세션 번호; 액세스가 거절되었습니다. ora-00023 세션이 프로세스 고유의 메모리를 참조함; 세션을 분리할 수 없습니다. ora-00024 단일 프로세스 모드에서는 하나 이상의 프로세스가 로그인할 수 없습니다. ora-00025 %s에 메모리를 할당하는데 실패했..