다음 쿼리를 재작성하라.  문제 쿼리에 order by는 없었지만 결과 확인할 때 편하도록 넣었다.  

결과는 5개 밖에 안 되는데 주문 테이블에서 45185줄을 다 스캔해버린다.게다가 고객 테이블은 고객 20명 밖에 안 된다.02김철수, 05홍길동은 겹치지 않으므로 union all이 가능하다.부분범위처리를 해준다. NL Join을 사용하도록 하자. 주문 테이블을 먼저

오라클 sysdba 접속하는 법bash> sqlplus /nologsql> conn sys/oracle as sysdbasql> grant sysdba to system;sql> commit;이후 계정 접속해서conn as sysdba 하고 아이디/비번 다시 입력

퀴즈3432, 441, 43, 4231RANK242POSITION IS NULL250% 80(1 - disk / (query+current))3441, 341322, 31431221334슈퍼타입과 서브타입을 변환하는 방식에서는 수직분할과 수평분할 방식이 존재하지 않는다

ORD_MATERIAL에 대해서 1년 단위로 파티션되어 있음ord_dt로 range scan 하도록 group by 튜닝?join 순서대용량이라는 내용은 없으므로 NL Join 가능할 듯order는 stat_cd가 01, 02 인 것들은 15만 건 order에서 st

643sum 함수에서, 레코드 안에서 칼럼끼리 합하는데 하나가 Null이면 Null이 나온다. 근데 각 레코드의 합 결과끼리 합할테는 결과가 Null이 나온 레코드를 무시하고 합한다.1 - (20 + 70)으로 90이다.2 - 첫째 둘째 레코드는 무시되고 세번째 레코드

배치 프로그램은 일련의 작업들을 하나로 묶어 처리하는 것을 말한다.좀 더 자세히 말하면, 사용자와의 상호작용 없이 대량의 데이터를 처리하는 일련의 작업들을 묶어 정기적으로 반복하거나 정해진 규칙에 따라 자동으로 수행하는 것을 말한다.정해진 시점, 주로 야간에 정기적으로

파티셔닝(Partitioning)은 테이블 또는 인덱스 데이터를 파티션 단위로 나누어 저장하는 것을 말한다.테이블과 인덱스 데이터를 파티셔닝하면 파티션 키에 따라 물리적으로 별도의 세그먼트에 데이터를 저장한다.파티셔닝이 필요한 이유는 다음과 같다.관리적 측면: 파티션

그 동안은 조회를 위한 튜닝이었다.이제 데이터를 삽입/삭제하는 DML 튜닝에 대해 알아보자.인덱스는 사실 전적으로 조회를 위한 기능이다.데이터를 수정하면 인덱스도 그에 맞춰줘야 하므로 인덱스는 무조건 DML에 좋지 않다.Update를 수행할 때 테이블 레코드는 직접 변

Oracle 실행계획에 나타나는 오퍼레이션 형태를 기준으로 설명한다.전체 로우를 대상으로 집계를 수행할 때 나타난다.실제 소트를 하진 않으며, SQL Server에선 Stream Aggregate라고 표시된다.결과 집합을 단순히 정렬했을 때 나타나는 오퍼레이션이다.So

432index_asc이기 때문에 항상 오름차순으로 간다. 시작점은 deptno = 20, sal=2000이다. 오름차순이고, 조건이 comm<=100이기 때문에 comm=100에서 시작할 순 없다.만약 comm >= 100이 조건이었다면 deptno = 20,

조인 방법에는 크게 세 가지가 있다.1\. Nested Loop Join (NL Join)2\. Sort Merge Join3\. Hash JoinNested Loop Join은 단순한 이중포문으로 구현된다.여기서 바깥 for문에서 쓰이는 table_a를 outer라고

인덱스 변형함 가공, 함수 씌우기, 형변환 등부정형 where id != '123' where idx is null: 검색이 안 됨where idx is not null : 오라클은 인덱스에 null 안 넣어서, 필터링 효과가 전혀 없음where idx1 is n

인덱스는 테이블과 같이 세그먼트 단위로 존재한다.인덱스는 테이블의 Skinny 한 버전으로, 테이블의 row(s)를 포함하는 블록은 너무 크기 때문에 한 번 거쳐가는 단계로서 존재한다.인덱스도 블록 단위로 존재하기 때문에 인덱스를 거치는 개수도 중요하긴 하다.인덱스 전

비용이란 기본적으로, SQL 수행 과정에 수반될 것으로 예상되는 I/O 일량을 계산한 것이다.데이터베이스 Call 발생량도 옵티마이저의 중요한 비용 요소다.옵티마이저가 비용을 계산할 때, CPU 속도, 디스크 I/O 속도 등도 고려할 수 있다.최신 옵티마이저는 I/O에

옵티마이저의 3개 서브머신, Query Transformer, Plan Generator, Estimator 중 Query Transformer는 더 나은 실행계획을 위해 사용자가 작성한 쿼리를 같은 결과를 보장하는 한에서 수정하기도 한다.서브 쿼리는 쿼리 안의 쿼리로

SQL과 옵티마이저에 대해 읽고 오자.옵티마이저는 규칙기반과 (Rule-Based Optimizer, RBO)와비용기반 (Cost-Based Optimizer, CBO)로 나뉜다.RBO는 미리 정해진 일정 규칙에 의거해 옵티마이징을 한다. 규칙들에는 우선순위가 있으며

트랜잭션의 원자성을 훼손하지 않는 선에서 트랜잭션을 가능한 짧게 정의할 것같은 데이터를 갱신하는 프로그램이 가급적 동시에 수행되지 않도록 트랜잭션을 설계할 것select 문장에 for update 문장을 사용하지 말 것온라인 트랜잭션을 처리하는 DML 문장을 1순위로

code runner 확장 설치하고확장 설정에서 settings.json에서 편집csharp 부분 수정(이 예시는 namespace와 클래스명이 \\\_파일명임)($fileNameWithoutExt는 확장자 제외한 파일명)Ctrl + Alt + N 누르면 실행여기에서

Lock 트랜잭션의 순차적 진행을 보장할 수 있는 직렬화(Serialization) 장치로, DBMS마다 Lock 메커니즘을 구현하는 방식과 세부적인 기능이 다르다. Lock의 종류 공유 Lock 배타적 Lock 갱신 Lock 의도 Lock 스키마 Lock B