시행착오와 배움을 기록하는 공간

회사 업무에서 trigger 관련 업무를 하게 되어, trigger에 대한 개념을 확인하고 간단한 실습을 해보았다. 아래 블로그를 보며 개념을 익히고 간단한 실습을 진행하였다. 트리거(TRIGGER) 란 무엇인가? 실습을 통한 기초 이해하기 오늘 포스팅에서는 트리거에 대한 기초를 간단한 예제를 통해 이해하도록 해보겠습니다. 트리거에 대한 깊은 내용은 추후에 다루도록 하겠습니다. 트리거(TRIGGER) 테이블에 대한 이벤트에 반응 hanhyx.tistory.com 트리거(Trigger)란? 테이블에 대한 이벤트에 반응해 '자동으로 실행'되는 작업을 의미한다. 테이블에 insert, update, delete 작업 발생 시 자동으로 실행되는 코드를 말한다. 어떤 트랜잭션이 일어나면 거기에 반응해서 다른 명령..

1.3 데이터 저장 구조 및 I/O 메커니즘 I/O 튜닝이 곧 SQL 튜닝이라고 해도 과언이 아니다. SQL이 느린 이유 SQL이 느린 이유는 십중팔구 I/O 때분이다. 구체적으로, 디스크 I/O 때문이다. I/O 가 무엇일까 ? I/O = 잠(SLEEP) 이라고 설명한다. OS 또는 I/O 서브시스템이 I/O를 처리하는 동안 프로세스는 잠을 자기 때문이다. 프로세스는 ‘실행 중인 프로그램’ 이며, 생명주기를 갖는다. 생성 이후 종료 전까지 준비와 실행과 대기 상태를 반복한다. 여러 프로세스가 하나의 CPU를 공유할 수 있지만, 특정 순간에는 하나의 프로세스만 CPU를 사용할 수 있기 때문에 이런 메커니즘이 필요하다. interrupt없이 열심히 일하던 프로세스도 디스크에서 데이터를 읽어야 할 땐 CPU..

1.2 SQL 공유 및 재사용 💡 SQL의 내부 최적화 과정의 복잡성을 알고 나면, 동시성이 높은 온라인 트랜잭션 처리 시스템에서는 바인드 변수가 중요하다. 라이브러리 캐시(Library Cache) SQL파싱, 최적화, 로우 소스 생성 과정을 거쳐 생성한 내부 프로시저를 반복 재사용 할 수 있도록 캐싱해두는 메모리 공간. SGA의 구성요소다. 소프트 파싱 vs 하드 파싱 사용자가 SQL문 전달 → DBMS가 SQL을 파싱 후 → 해당 SQL이 라이브러리 캐시에 존재하는지 확인 → 캐시에 존재 ? Y실행 단계 : N최적화 단계 SQL을 캐시에서 찾아 곧바로 실행단계로 넘어가는 것을 ‘소프트 파싱(Soft Parsing)’ 찾는데 실패해 최적화 및 로우 소스 생성 단계까지 모두 거치는 것을 ‘하드 파싱(H..

1.1 SQL 파싱과 최적화 SQL : Structured Query Language : 구조적 질의 언어 SQL은 기본적으로 구조적이고 집합적이고 선언적인 질의 언어다. 원하는 결과집합을 구조적, 집합적으로 선언하지만, 그 결과집합을 만드는 과정은 절차적일 수밖에 없다. 즉, 프로시저가 필요한데, 그런 프로시저를 만들어내는 DBMS 내부 엔진이 바로 SQL 옵티마이저이다. DBMS 내부에서 프로시저를 작성하고 컴파일해서 실행 가능한 상태로 만드는 전 과정을 ‘SQL 최적화’라고 한다. SQL 최적화 SQL 파싱 - 파싱트리생성, Syntax 체크, Semantic 체크 SQL 최적화 - 옵티마이저가 그 역할을 맡는다. 데이터베이스 성능을 결정하는 가장 핵심적인 엔진임 로우 소스 생성 SQL 옵티마이저 ..

오라클은 SELECT를 전달할 때 '힌트(hint)라는 것을 사용할 수 있다. 힌트 : 지금 내가 전달한 select문을 이렇게 실행해 주면 좋겠다 라는 힌트이다. 힌트는 select 문을 어떻게 처리하는지에 대한 힌트일 뿐이므로 힌트 구분에서 에러가 나도 SQL실행에 전혀 지장을 주지 않는다. 힌트는 개발자가 데이터베이스에 어떤 방식으로 실행해줘야 하는지를 명시하기 때문에 조금 강제성이 부여되는 방식이다. select * from tb_board order by bno desc; select *+INDEX_DESC (tb_board pk_board) */ * from tb_board; 위의 두 SQL은 동일한 결과를 생성한다. 힌트를 통해 인덱스 자체가 정렬을 해 둔 상태이므로 이를 통해서 SORT과정..

인덱스의 특징을 살펴보면, 1. 인덱스는 질의 결과를 빠르게 찾는데 목적이 있다. 2. 데이터베이스에 레코드가 삽입, 삭제될 때마다 인덱스가 변경되어야 한다. 3. 그런데 데이터베이스에서 인덱스는 별도의 자료구조(B-Tree)형태로 관리하게 된다. 인덱스 자료구조도 디스크에 저장하여, 질의가 있을 경우에 읽어와서 사용하게 된다. 여기서 3번이 인덱스가 많아지면 문제가 될 수 있는 부분에 해당한다. 한 테이블에 인덱스를 많이 걸면 성능이 안좋아진다는 얘기를 많이 들어봤을 것이다. 어떠한 이유로 성능이 안좋아지는 것일까 ? DB를 직접 만든다고 생각해보자. DB는 거대한 list에서 특정 item 을 찾기 위한 시스템이다. List users; list의 크기가 작을 때는 그냥 for-loop를 돌면서 일일..

집계함수는 group by랑 연동해서 작업이 이루어진다 aggregation function 그룹바이와 집계함수는 연동된다! 그룹별로 최저값, 최대값, 평균값 등 그룹별로 작업을 하는데 전체합계도 구하고, 동시에 그룹별 합계도 구하고 싶다! ? 합계뿐만 아니라 집계를 같이 구하고싶다! 전체 행들에 대한 집계와 그룹별로의 집계! 를 구하고 싶은 경우에 어떻게 해야 할까 ? 전체에 대해 집계를 돌리고 그룹별로 집계를 돌리고싶다. 그룹별 집계는 '소계' 라고 한다. 전체집계와 (소그룹의집계)소계를 같이 구하고싶다! 한번에 구하고싶다? 그럴때는 ? 1) ROLLUP 함수 GROUP BY ROLLUP(A) : 전체합계, 칼럼A소계 GROUP BY ROLLUP(A,B) : 전체합계, 칼럼A소계, 칼럼A,B조합 소계..

인덱스 사용자체를 기반으로 하는 조인 방식이다. 조인 수행 절차 하나의 테이블을 기준으로 각 row를 추출할 때마다 순차적으로 상대 테이블의 연관된 모든 row들을 조인에 의해 추출한다. 수행절차로부터 알 수 있는 튜닝 포인트에는 2가지가 있다. 1) 테이블사이에 조인이 발생하니 조인의 수를 최소화 하는것이 중요하다. 그걸 위한 차원에서 조인순서(driving)가 중요하다. 2) 연결되는 테이블은 반드시 연결고리 칼럼에 대한 인덱스가 사용되어야 한다. 조인조건에 대한 인덱스가 구성되어 있어야 하고, 그것이 사용되어야 하는 것이 중요하다. 특징 1. 인덱스에 의한 랜덤 액세스에 기반을 두며 인덱스 사용을 하는 이상 대용량 데이터를 처리하게 될때는 I/O로 인해서 문제가 발생될 가능성이 있다는 것이 특징이다..