728x90
반응형

데이터타입 종류 

 

정수(integer) - INT 

 

실수형데이터타입 - DOUBLE 소수점까지 표현가능 

 

문자열 - TEXT  

 

member table의 식별키 - id 

 

NN - NOT NULL(널이 아니다)

 

NOT NULL - 적용 값에는 반드시 어떤 값이 들어가야 한다.

 

NULL - 값이 존재하지 않는 상태  

 

NULL은 값이 없다는 의미  

 

Primary key - 테이블에서 하나의 row를 고유하게 식별할 수 있도록 해주는 column

 

Primary key는 반드시 NOT NULL 

 

1.Natural Key 

 

실제로 어떤 개체가 갖고 있는 속성을 나타내는 컬럼이 Primary Key가 됐을 때 이를 Natural Key라고 한다.

사람은 주민번호 책은 ISBN으로 

 

2.Surrogate Key 

 

설정했던 id 컬럼같은 Primary Key를 의미 어떤 회원의 속성을 직접적으로 나타내는 컬럼은 아닙니다.

제가 Primary key로 사용하기 위해 인위적으로 생성한 컬럼 입니다. 어떤 개체의 실제 속성은 아니지만

Primary key로 쓰기 위해 추가한 컬럼을 Surrogate key라고 합니다. 

 

보통은 Surrogate Key를 많이 쓴다. 

 

 

반응형
728x90
반응형

1. 옵티마이저의 개념 

 

- 사용자가 실행한 SQL을 해석하고 데이터를 추출하기 위한 실행계획을 수립하는 프로세스

 

2. 옵티마이저의 종류 

 

RBO 

 

- 규칙기준 옵티마이저는 인덱스 구조나 사용하는 연산자에 따라 부여되는 순위가 정해져 있음

 

CBO 

 

- 대상 ROWS를 처리하는데 필요한 자원사용을 최소화해서 데이터를 빨리 처리하는데 목적이 있음 

 

3. 옵티마이저 레벨별 설정 

 

데이터베이스 전체에 지정 

 

[initSID.ora를 이용해서 지정]

OPTIMIZER_MODE=[RULE/CHOOSE/FIRST_ROWS/ALL_ROWS]

 

세션별로 지정 

 

SQL > ALTER SESSION SET OPTIMIZER_MODE =

         [RULE/CHOOSE/FIRST-ROWS/ALL-ROWS]

 

각 SQL 별로 지정 

 

SQL > SELECT/ * first_rows * /

                     ename 

         FROM EMP ; 

RBO와 CBO의 실행계획 비교 

 

- 동일 SQL에 대해서 각 옵티마이저가 수립한 실행계획은 다를 수 있음 

- SQL 퍼포먼스가 옵티마이저에 따라 다르다는 의미 

- 옵티마이저의 종류에 따라 달라지는 DB성능 차이점을 이해하는 것이 중요 

 

4. 인덱스 

 

사용자가 인덱스를 사용하는 이유 

 

- 데이터베이스에 저장된 자료를 더욱 빠르게 조회하기 위해 인덱스를 생성하여 사용함 

 

- 모든 SQL이 인덱스를 사용해야만 하는가 ? 

 

일반적으로 인덱스는 테이블의 전체 데이터 중에서 10 ~ 15% 이하의 데이터를 처리하는 경우에

효율적이며 그 이상의 데이터를 처리할 땐 인덱스를 사용하지 않는 것이 더 나음 

 

5. B*Tree 구조 

 

- 가장 많이 사용되는 인덱스의 구조라 할 수 있으며,

  인덱스의 데이터 저장 방식이기도 함 

- Root(기준)/Branch(중간)/Leaf(말단) Node로 구성됨 

 

- Branch 노드는 Leaf 노드에 연결되어 있으며

  조회하려는 값이 있는 Leaf 노드까지 도달하기 위해 

  비교/분기해야 될 값들이 저장됨 

 

Leaf 노드 = 인덱스 칼럼의 값 + ROWID 

 

인덱스 칼럼의 값 : 오름(내림)차 순으로 Sort되어 저장됨 

ROWID : 테이블에 있는 해당 row를 찾기위해 사용되는 논리적인 정보

 

Brancg Blocks - RootNode(뿌리),Branch Node

Leaf Blocks - Sorting,Leafnode

 

6.B*Tree 구조 

 

B*Tree 구조의 핵심은 Sort 

01 ORDER BY에 의한 Sort를 피할 수 있음 

02 MAX/MIN의 효율적인 처리 가능함 

 

7.인덱스 선정 절차 

 

1. 프로그램 개발에 이용된 모든 테이블에 대하여 Access Path 조사

2. 인덱스 칼럼 선정 및 분포도 조사 

3. Critical Access Path 결정 및 우선 순위 선정

4. 인덱스 칼럼의 조합 및 순서 결정 

5. 시험 생성 및 테스트 

6. 결정된 인덱스를 기준으로 프로그램 반영

7. 실제 적용 

 

8.인덱스 생성 및 변경시 고려할 사항

 

1. 기존 프로그램 동작에 영향성 검토 

2. 필요할 때마다 인덱스 생성으로 인한 인덱스 개수의 증가와 이로인한 DML 작업의 속도 

3. 비록 개별 칼럼의 분포도가 좋지 않을지라도 다른 칼럼과 결합하여 자주 사용되고 

  결합할 경우에 분포도가 양호하다면 결합 인덱스 생성을 긍정적으로 검토 

 

9.인덱스 스캔의 원리 

 

옵티마이저가 인덱스 사용을 위한 실행계획 수립함.

 

1. 조건을 만족하는 최초의 인덱스 row를 찾음 

2. Access된 인덱스 row의 ROWID를 이용해 테이블에 있는 row 찾음 (Random Access)

3. 처리 범위가 끝날때까지 차례대로 다음 인덱스 row를 찾으면서 스캔을 반복함

 

인덱스 스캔시에는 한 번의 I/O가 발생할때 마다 한 개의 Block을 처리함 

 

ROWID의 분해 

 

ROWID(4개의 정보) = 데이터의 저장 주소 

 

데이터의 저장 주소 

 

- 데이터를 가진 테이블 정보 

- 테이블 공간을 구성한 파일 경보 

- Block에 대한 정보 

- Row 

 

고유(Unique) 인덱스의 Equal(=) 검색

 

ex) SELECT * FROM emp WHERE empno = 7788;

고유(Unique) 인덱스의 범위(Range)검색 

 

SELECT * FROM emp WHERE empno >= 7654;

SELECT * FROM emp WHERE empno >= 7654;

 

중복인덱스의 범위 검색 

 

CREATE INDEX job_index on emp (job);

SELECT * FROM emp WHERE job Like 'SALE%'

SELE

 

OR & IN 조건 - 결과의 결합 

 

1. SELECT * FROM emp WHERE empno IN (7654,7788);

2. SELECT * FROM emp WHERE empno = 7654 OR empno = 778

 

인덱스 머지 . 결합인덱스 

 

인덱스 머지란 개별 칼럼에 인덱스가 생성되어 있으면서 모두 where절에 Equal(=)조건으로

사용되어, 각각의 인덱스 조합으로 자료에 접근하는 것을 의미 

일반적으로 결합인덱스를 사용할 경우, 좋은 엑세스 경로를 제공 

 

결합인덱스의 구성 

 

결합인덱스 칼럼 순서 결정

 

- where절 조건에 많이 사용되는 칼럼 

- Equal로 사용되는 칼럼

- 분포도가 좋은 칼럼

- 자주 이용되는 Sort의 순서로 결정

 

결합인덱스 사용 방법

 

- 결합인덱스의 첫 번째 칼럼이 where절에서 제외되어 있는 경우, 결합인덱스를 사용할 수 없음 

- 인덱스 스킵 스캐닝 

  결합인덱스의 첫 번째 칼럼이 WHERE절에 제외되어 있고, 두 번째 칼럼부터 WHERE절에 조건으로 기술되어 있는 경우에도 그 인덱스가 사용되는 경우 

 

결합인덱스 칼럼에 대한 '='의 의미

 

범위 제한 조건 

 

- 결합 인덱스의 선행하는 칼럼 순서로 WHERE절에 '='로 연속된 경우,

해당하는 조건을 범위제한 조건이라 함 

 

- 체크 조건 

- WHERE절 조건에서 선행 칼럼이 '='조건에 없다면 후행 조건은 체크조건이 됨 

 

- 인덱스 매칭률 =

 

반응형
728x90
반응형

데이터베이스 튜닝에 대해 언제,누가,어떻게,무엇을 왜 하는지 살펴보고자 한다 ~ !! 

 

데이터베이스 튜닝이란 ??

 

데이터베이스의 성능 향상을 위하여 운영체제나 DB자체의 구조를 이해하고 필요한 요소를 변경하는 작업을 말한다.

데이터베이스를 단순히 데이터의 저장과 인출 등의 목적으로만 활용하는 것이 아니라 실제 서비스 운영에 있어 성능은 매우 중요한 요소이다. 

단순히 하드웨어의 퍼포먼스를 향상시키는 방안이 아니라 자주 호출하는 SQL이나 프로그램에서 호출되는 SQL의 경로 등을 운영체제나 다른 미들웨어 영역까지 확장하여 주어진 자원을 범위로 성능을 향상시킬 수 있는 범위를 탐색하는 것이 중요하다. 

 

데이터베이스 튜닝의 3단계

 

데이터베이스 설계 튜닝 : 데이터베이스 설계단계에서 성능 고려 

데이터베이스 환경 튜닝 : 성능을 고려하여 메모리나 블록 크기 등을 지정 

SQL문장 튜닝 : 성능을 고려하여 SQL 작성하고 쿼리 문장을 수정 

 

데이터베이스 튜닝 왜 할까 ? 

 

데이터베이스 튜닝은 주어진 H/W 환경을 통해 처리량과 응답속도를 개선하기 위해 수행한다. 시스템 운영 중 다양한 애플리케이션의 도입과 데이터베이스 내 데이터량과 환경이 지속적으로 변화하고 또한 이를 호출하는 프로그램과

SQL이 잦은 수정을 거치게 되면 데이터베이스는 성능을 보장할 수 없다. 이에 따라 성능저하가 발생하면 

시스템의 안정과 사용자의 만족등을 위해 정기적인 데이터베이스 튜닝이 필요하다.

 

데이터베이스 튜닝 누가 할까 ?

 

데이터베이스 성능 튜닝은 다양한 업무 영역에서 실시 한다.

 

응용프로그램 설계자 : 응용시스템 영역에서 시스템 재디자인

응용프로그램 개발자 : SQL 문장 레벨에서 힌트를 수정하는 효율적인 SQL 쿼리문장 수정 

DBA : 비정상적인 시스템 수치를 모니터링하고 이와 관련한 DB 파라미터 수정 

H/W,S/W,OS 관리자 : 시스템 레벨에서 원인을 파악하고 환경을 개선하고자 패치 권고 

 

하지만 시스템 구조 자체를 건드는 일은 운영 서비스 전체의 광범위한 영향을 미칠 수 있으므로 문제를 탐색하고 

발생한 문제 지점만을 효율적으로 진단하고 해결할 수 있는 지엽적인 처방이 우선시 되어야 합니다.

 

데이터베이스 튜닝 언제 할까 ? 

 

데이터베이스 튜닝은 시스템 계획.분석 및 설계,개발 및 검수, 시스템 운영 전 단계에 걸쳐서 수행

다만 각 단계에 맞는 튜닝방은들이 있으며 시스템 설계단계에서 부터 적극적으로 성능을 고려하여야만 추후에 튜닝에 대한 이슈가 적어질 수 있다. 이에 따라 시스템 개발 그 자체에 목적을 두는 것이 아닌 효율적인 시스템을 설계하고 개발하는데 전념 해야 한다. 

 

시스템의 문제를 분석하고 성능 목표를 결정하고 튜닝을 실시한다. 데이터베이스 튜닝을 위해 OS,DB,WAS 등의 영역에서 시스템 레포팅을 참조할 수 있다. 이에 따라 성능이 떨어지는 프로그램을 발견하거나 특정시점이나 환경에 저하될 수 있는 상황 등을 탐지할 수 있다. 이에 문제를 정확히 분석하고 이를 원천적으로 해결할 수 있는 다양한 방법을 시도해볼 수 있다. 위에서 언급한 바와 같이 시스템 전체 영역에 영향을 미치는 경우 서비스에 정상적인 운영을 오히려 방해하는 경우가 생기므로 파급 영향을 함꼐 고려해야 한다. 

 

반응형
728x90
반응형

디비의 기본 쿼리란 ?? 

 

구글 번역으로 쿼리는 질문,문의하다라는 뜻이다.

질문의 답을 달라는 요청인 것 같다. ㅇㅅㅇ

 

쿼리는 데이터베이스에 하는 요청으로 데이터를 달라고 요청한다 ~ !! 

 

쿼리는 데이터베이스에게 특정한 데이터를 보여달라는 클라이언트의 요청을 말한다 ~ !! 

 

이에 쿼리문을 작성한다는 말은 데이터베이스에서 원하는 정보를 가져오는 코드를 작성한다의 뜻으로

이해하면 된다. 쿼리문을 잘 작성한다는 것은 데이터베이스에서 필요한 데이터를 발빠르게 접근하여

데이터를 능숙하게 핸들링한다는 말로도 볼 수 있다. 

 

 

반응형
728x90
반응형

데이터베이스란 ? 

 

대량의 정보를 컴퓨터가 효율적으로 접근할 수 있도록 가공 및 저장한 것 

 

DBMS란 ?

 

다수의 사용자들이 데이터베이스 내의 데이터를 접근할 수 있도록 해주는 소프트웨어 도구의 집합

 

DBMS를 쓰지 않는다면

 

다수의 사람이 데이터를 공유하기 어렵다 

대량의 데이터를 다루기 어렵다 (txt,xls 등)

읽기/쓰기를 자동화하려면 프로그래밍 기술이 필요하다. 

만일의 사고에 대비 어렵다.

 

관계형 데이터베이스 - RDB 

 

관계형 데이터베이스는 키와 값의 간단한 관계를 2차원 표(테이블)형식으로 나타낸 데이터베이스이다. 

하나의 데이터베이스 안에는 여러 개의 테이블이 존재할 수 있다.

 

테이블

 

테이블은 행과 열로 이루어져 있다. 

 

테이블의 행은 레코드라고 브르며 데이터 한 건에 해당 

하나의 테이블은 적게는 수백개 많게는 수백만개의 레코드를 지님. 

 

 

테이블의 열에 해당하는 칼럼은 각기 구분하기 쉽게 이름을 붙여 분류 

칼럼은 특정한 데이터 타입을 가진다.

 

RDBMS는 일반적으로 클라이언트가 요청을 보내면 서버가 처리해주는 C/S구조로 되어있다.

클라이언트가 요청을 보낼때에 주로 사용하는 언어가 SQL이다.

 

사용자가 데이터를 조회하고 싶을때에 SQL문으로 작성한 요청을 RDBMS에 보내면 RDMBS는 요청된 데이터를 반환한다. 이 때 RDMBS는 2차원 표 형태의 데이터를 반환한다.

 

RDBMS의 종류 

 

어떤 RDBMS를 쓰는지에 따라 SQL 문법이 조금씩 달라진다. 쓰이는 인기 있는 RDBMS는 

아래와 같다.

 

Oracle DB - 가장 오래되었고 신뢰도도 높다. 뛰어난 기술력과 안정성을 가지고 있다. 대규모의 애플리케이션,

특히 은행 업계에서 쓰이며 유료로 사용 

MySQL - 오픈 소스이기 때문에 널리 쓰인다. 웹 개발 특히 PHP를 이용한 개발에 흔히 쓰인다. 오라클이 인수한 후

불안감 때문에 다른 곳으로 넘어가는 경우가 보임

Maria DB -오라클이 MySQL을 인수하면서 라이선스 문제가 불확실해지자 이에 반발하여 만들어졌다.

MySQL 5.5를 기반으로 만들어져 사용법이 거의 유사하고 호환성도 뛰어나다.

PostgreSQL - 버클리 대학의 프로젝트로 만들어진 오픈 소스 ORDBMS이다. 

(ORDBMS : 객체 - 관계형 데이터베이스 관리 시스템) SQL의 확장성과 표준을 준수하고 풍부한 기능을 지원한다.

SQL Server - 마이크로소프트가 개발한 RDBMS이기 때문에 윈도우 시스템 환경 지원 

SQLite - DB를 서버가 아닌 파일로 저장하는 DBMS이다. 기기에 가벼운 DB를 저장하는 목적으로 설계되었으며

대표적으로 안드로이드,iOS,mac OS에서 사용 

 

SQL 명령어 

 

DDL - 데이터베이스 스키마와 설명을 처리하는 정의하는 언어. 데이터베이스나 테이블 생성/변경/삭제 등의 작업이 여기 포함된다. 

DML - 데이터검색,삽입,변경.삭제를 수행하여 조작하는 언어.실질적으로 저장된 데이터에 처리할 때 사용 

DCL - 데이터에 접근할 수 있는 권한을 관리하는 언어

TCL - 트랜잭션을 다루는 언어 

 

반응형

+ Recent posts