728x90
반응형

요새 공모주 맛에 들리기도 하고 

현금 비중을 늘리려고 환전을 잘 안하고 있다.

그 와중에 테슬라는 다시 천슬라가 갔다..

400달러에 사서 700~800달러에 팔았는데..

테슬라를 의심했던 거 같다.

배당금도 안줘서 팔았는데.. 

 

그래도 애플,마소,엔비디아가 

나에게 많이 벌어주고 있다. 

 

버거킹을 좋아해서 

 

QSR을 매수

 

QSR - 1.35

알트리아 - 9.94

DIA - 0.63

TSMC - 4.66

O - 3.21

 

이렇게 배당금을 받았다.

현시각 환율 기준으로 

2만 3천원을 받았다.

 

QSR과 알트리아는 배당은 많이주지만..

빌빌 긴다 주가는 

TSMC도 올해는 영 힘을 못쓰는 것 같다. 

 

 

반응형
728x90
반응형

실행계획 - 데이터를 처리하고자할때, 수립되는 데이터 처리 방법 

 

실행계획을 하는 이유

 

- 비효율적인 부분 확인 가능 

- 실행계획을 통해 SQL 튜닝 포인트 도출 

 

EXPLAIN PLAN - 실행계획만 확인 가능한 방법 

 

SET AUTOTRACE

 

- 실행계획과 I/O관련 정보 확인 가능 

- 한 번의 명령으로 여러 개의 SQL에 대한 실행계획 볼 수 있음 

 

옵티마이저

 

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

 

오라클 

 

RBO(초창기버전부터 제공) 

 

CBO(Vlog부터 기본적인 설정으로 적용)

 

RBO(Rule Based Optimizer)

 

- 기본적으로 15개의 순위가 매겨진 규칙이 있음 

  -> 이를 기초로 해서 실행계획을 수립함. 

 

- SQL에 대한 실행계획이 하나 이상일 경우엔 

  순위가 높은 규칙을 이용

 

- 수립될 실행계획이 예측 가능하기에 

  개발자가 원하는 처리 경로로 유도 하기 쉬움 

 

CBO(Cost Based Optimizer)

 

- 대상 row들을 처리하는데 자원 사용 최소화함 

  궁극적으로 데이터를 빨리 처리하는게 목적 

 

- CBO에 영향을 미치는 비용 산정 요소 

  각종 통계정보,Hint,연산자,Index

 

- Cluster,DBMS버전,CPU/Memoy 용량 

Disk I/O등과 같이 매우 다양함 

 

통계정보 -> 주기적으로 생성

 

CBO의 성능을 최적의 상태로 유지시키기위해 테이블,

인덱스,클러스터 등을 대상으로 통계 정보 생성 

 

-> 정기적으로 ANALYZE 작업을 하는 것이 가장 중요 

 

-> 가장 효율적인 실행계획을 수립하기 위해 

    최소 비용을 계산할때 중요하게 사용

 

RBO

Rank  Access Path
1 Rowid에 의한 1row
2 클러스터 조인에 의한 1row
3 unique나 Primarykey를 사용한 해시클러스터 키에 의한 1row
4 Unique나 Primary key에 의한 1row 
5 클러스터 조인
6 해시 클러스터키
7 클러스터키
8 결합 칼럼 인덱스
9 단일 칼럼 인덱스
10 인덱스에 의한 유한영역
11 인덱스에 의한 무한영역
12 소트머지 조인
13 인덱스로 구성된 칼럼 최대 or 최소
14 인덱스로 구성된 칼럼 ORDER BY
15 인덱스 없이 전체 테이블 스킨 
(FTS:Full Table seam)

옵티마이저의 레벨별 설정 

 

Instance Level : initSID.ora를 이용해서 지정 

OPTIMMZER_MODE = 

[RULE/CHOOSE/FIRST_ROWS/ALL-ROWS(기본값)

 

Sesssion Level 

SQL > ALTER SESSION SET OPTIMIZER_MODE = 

[RULE/CHOOSE/FIRST_ROWS/ALL_ROWS]

 

State ment Level

SQL>SELECT/*First_rows*/

       ename 

FROM emp; 

 

RBO와 CBO의 비교 

 

SELECT e.ename,d.dname 

 FROM emp e,dept d 

WHERE e.deptno = d.depto 

 AND e.deptno = 10; 

CBO 

 

 

반응형
728x90
반응형

오라클 클라이언트 설치 이유가 

해당 파일로 WMS 접속하려고 했던 건데

이거 위치 설정도 진짜 애매하다.. 

환경 변수 설정하란 포스팅도 보고

이것 저것 봤지만 

 

이것때문에 실질적으로 많이 해멘 것 같다. 

해당 폴더를  D:\app\client\사용자 계정\product\19.0.0\client_1\network\admin폴더에 연동하니까

됐다. 

tnsnames.ora를 받은 건데 이거를 메모장으로 연결프로그램 설정하고

해당 폴더에 넣으면 쉽게 접속 됐따.. 

 

이게 연동 되기전까진 사용자 계정을 치라니

어쩌니 진짜 많이 헤맸다.. 

 

그 외에 설치과정에서 각종 에러는 

 

환경 변수 설정 

32bit로 설치(권장) 64bit로 하니까 잘 안됨..

오렌지가 잘안되면 오렌지 재설치 

 

이것저것 해보면서 

오라클 셋팅하는데만 2~3일 걸린 것 같다..

ㅂㄷㅂㄷㅂㄷ

 

 

반응형
728x90
반응형

많은 시행착오를 겪은 탓에 

정리하여 올린다. 

이게 뭐라고 몇시간동안 낑낑 됐다.. 

구글링을 해서 여러 설치 방법을 

봤는데도 오래된 포스팅도 있어서 

상당히 많이 헤맸다.

 

https://www.oracle.com/downloads/#category-database

 

먼저 해당 사이트에 들어간다. 오라클은 다운로드창 들어가는데도 헤맸다.

Database - instant Client 

 

접속하면 아래와 같은 창이 뜨는데 맞는 운영체제를 선택 하면 된다. 

MS 64비트 운영체제를 선택하면 아래와 같은 창이 뜬다. 

 

해당란의 버전을 다운로드 하면 된다. 

시간이 지남에따라 최신버전을 설치하면 되겠다.. 

 

압축을 C 안에 풀기를 권장한다. 

 

오라클 폴더 안에 여기다 놓으면 괜찮을 것 같네요. (솔직히 위치는 중요한 것 같지 않다.) 

 

 

>> 책 구매 바로가기 <<

 

"이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다."

반응형

'IT > DB' 카테고리의 다른 글

SQL 튜닝 실행계획 및 옵티마이저  (0) 2021.11.01
tnsnames.ora 접속하는 방법  (0) 2021.10.26
SQL 개념 정리  (0) 2021.10.20
왜 데이터베이스 튜닝을 해야할까 ?? -  (0) 2021.10.14
쿼리란 ?  (0) 2021.10.14
728x90
반응형

데이터베이스 

 

- 데이터 파일과 로그 파일로 구성됨 

- 데이터 파일 : mdf,ndf 확장자

- 로그 파일 : ldf 확장자

- 다양한 형태의 개체 포함 

(테이블,인덱스,프로시저,트리거,함수)

 

테이블 

 

- 데이터베이스 내의 존재하는 대표적인 개체 

  (데이터를 가지고 있다.)

- 시스템 테이블 & 사용자 테이블 

- 실제 데이터를 물리적으로 포함하고 있음

- 행과 열로 구성 됨

 

페이지 

 

- 페이지 파일을 구성하는 논리 단위 

- SQL Server의 기본 데이터 저장단위(8KB)

- 데이터를 쓸 때 행을 페이지에 기록함 

- 데이터를 읽을 때(SELECT)

  페이지 내의 모든 행이 읽혀짐

- 페이지 내의 행이 많을수록 I/O 효율 증가 

- 0 ~ N 사이의 순차적인 번호를 가짐 (페이지 번호)

 

레코드 100개를 읽어야 할 경우 (SELECT)

 

페이지(8KB)에 레코드 10개 들어있는 경우는 10번 

페이지(8KB)에 레코드 100개 들어있는 경우는 1번만

읽으면 되기 때문에 1번 읽어서 레코드 100개를 

읽어주는 것이 성능이 더 좋다. 

 

인덱스 이해 

 

EX) 인덱스는 주민센터다.

- 사람을 빨리 찾을 수 있게 해준다.

 

EX) 인덱스는 도서 검색 시스템이다. 

- 그 책을 가장 빨리 찾을 수 있게 해준다. 

 

EX) 인덱스는 다리다. 

-강 건너 그 곳에 가장 빨리 갈 수 있게 해준다.

(멀리 돌아갈 곳을 다리위로 가로질러서 건너간다.)

 

위의 3개의 공통점은 "빨리"이다. (인덱스 없이는 빨리 갈 수 없다.)

 

인덱스 장점 

 

 빠른 데이터 검색 

 - 찾는 데이터를 가지고 있다면 직접 주거나 

   없다면 어디에 있는지 알려준다. 

 

데이터 중복을 방지

- PRIMARY KEY 제약조건  

  (PK 생성시 UNIQUE Clustered Index 자동 생성됨)

- UNIQUE 제약조건

 

잠금 최소화 

- 최소 범위의 잠금을 가능하게 해 준다.

(인덱스를 참조하여 원하는 데이터를 빨리 찾을 수 있기 때문에 Update를 빨리하고 나오게 된다.)

- 동시성을 높여 준다.

(Update를 빨리하고 나오기 때문에 많은 사용자가 동시에 동일한 데이터를 엑세스 할 수 있게 된다)

 

인덱스 단점 

 

물리적인 공간 차지 

- 인덱스는 테이블처럼 데이터를 가짐 

- 테이블처럼 물리적인 공간을 차지함 

 

인덱스에 대한 유지관리 부담

- SELECT 문은 인덱스를 좋아함 

- INSERT 문은 인덱스를 별로 좋아하지 않음 

  (데이터를 추가하면 인덱스에도 등록해야해서)

 

데이터가 극히 적다면

- 인덱스가 있어도 사용되지 않을 수 있음 

- 얻는 효과보다 유지관리 부담이 클 수 있음 

 

인덱스 조각화 

 

내부 조각화

- 인덱스 페이지가 꽉 차지 않고 비어있는 상황 

- OLTP성 테이블의 인덱스라면 빈공간 확보(내부 조각화)가 필요하다.

- OLAP성 테이블에서는 빈공간이 많으면 조회할 때 읽는 페이지 수가 증가하여 성능이 떨어질 수 있다.

  (따라서 페이지 분할이 덜 발생하기 때문에 꼭 나쁘다고 할 수 없다.)

 

외부 조각화 

- 인덱스의 논리적인 순서와 물리적인 순서가 맞지 않는 경우로 성능에 도움이 되지 않으므로 제거해야 한다.

   (인덱스 순서가 흩어져 있는 것)

- 인덱스 리빌드 목적

  

인덱스 유지관리의 필요성 

 

- 재생성 또는 재구성 작업 자동화 

- 모든 인덱스를 대상으로 하는 것은 바람직 하지 않음 

 (인덱스 재생성 또는 재구성은 CPU 부하를 유발)

 

인덱스 조각모음은 인덱스 스캔(전체 조회)를 빠르게 해주는 것이지 인덱스 SEEK(조건으로 값 찾기)와는 상관이 없다.

만약 쿼리문에서 WHERE 조건을 지정해서 특정 값만 가져 오도록 쿼리를 만들었는데 인덱스 스캔한다면

쿼리 튜닝(인덱스 생성)이 필요하다.

 

테이블과 인덱스 

 

테이블의 존재 형태 2가지 

- 힙 테이블 

- 클러스터형 인덱스 테이블 

 

인덱스 종류 

- 클러스터 인덱스 

- 비 클러스터 인덱스 

 

힙이란 ? 

 

정렬 기준이 없이 저장 된 테이블의 존재 형태 

- 데이터 페이지 내의 행동들 간에 순서가 없음 

- 데이터 페이지들 간에도 순서가 없음 

 

- 클러스터 형 인덱스가 없는 테이블 

 

아무렇게나 쌓여 있음

 

힙의 장점과 단점 

 

- INSERT문이 좋아하는 테이블의 형태

- 새로운 행을 기존 페이지의 빈 곳에 추가하면 됨

- 빈 공간이 없으면 새로운 페이지에 추가하면 됨 

 

- SELECT문이 싫어하는 테이블 형태 

- 데이터가 극히 적으면 상관이 없음 

- 데이터가 많으면 원하는 데이터 찾기가 너무 힘듦

 

SELECT를 위한 테이블인가 INSERT를 위한 테이블인가. 

 

INSERT를 위한 테이블이라면 힙 테이블로 유지해야 하지만.

SELECT를 위한 테이블이라면 대처가 필요(인덱스 생성)

 

힙의 원하는 데이터 찾아가기 

 

Table Scan 

 

- 데이터를 찾을 수 있는 유일한 방법 

- 모든 데이터 페이지를 다 읽어야 함 (다 읽음)

- 참고 : IAM 페이지를 참조해서 

해당 데이터를 모두 읽게 됨 

 

클러스터 형 인덱스란 ? 

 

- 특정 열을 기준으로 데이터가 정렬됨 

- 물리적 정렬이 아닌 논리적 정렬 

- 정렬 기준의 열로 찾는데 빠른 성능을 보여줌 

 

- 테이블 당 하나의 클러스터 형 인덱스 설정 가능 

- 실제 데이터를 가지므로 하나만 존재 가능 

- 테이블을 여러 개 만들면 여러 개 존재 가능 

 

힙 -> 클러스터형 인덱스 

 

힙테이블 

클러스터형 테이블

인덱스 키 이름을 기준으로 데이터 페이지가 정렬되어 있다.

 

 

테이블 존재 형태의 문제 

 

힙 테이블로 둘 것인지, 클러스터형 테이블로 만들어서 정렬시킬 것인지 

장/단점이 있으니 충분한 고민이 필요 

 

클러스터형의 원하는 데이터 찾아가기 

 

Clustered Index Scan 

- 모든 데이터 페이지를 읽음 

- Table Scan과 크게 다를 바 없음 

- 데이터가 많은 경우 성능 문제 발생 

 

Clustered Index Seek 

- 특정 데이터를 클러스터 인덱스에서 찾음 

- 아주 빠른 성능을 보여줌

인덱스 구조

클러스터형 인덱스 유일성 지정 

 

UNIQUE Clustered Index 

- 인덱스 키 열에 중복된 데이터가 추가되는 것을 차단함

 

UNIQUE 속성을 생략하면 

- 기본적으로 UNIQUE 하지 않은 인덱스가 생성됨 

  그래서 내부적으로 유일성을 확보하기 위한 값이 사용됨 

  (공간 낭비가 되기 때문에 명시해 주는게 좋다)

 

UNIQUE 여부를 명확히 설정 

- 인덱스 키 열의 유일성을 우리가 아는게 중요한 것이 아니고 

  SQL SERVER가 아는 것이 중요

 

클러스터형 인덱스는 만능이 아님 

 

인명 전화번호부에서 서대문구 주민을 찾으려면 

 

- 전화번호부를 처음부터 끝까지 다 읽어야 함

  (이름으로 정렬되어 있기 때문)

 

A 열을 기준으로 정렬된 데이터에서 

 

- A로만 찾는다면 좋겠지만 

EX) WHERE A=10 (인덱스 활용)

 

- B 또는 C 등 다른 열로 찾는 경우 의미가 없어짐 

EX) WHERE B=5 (인덱스 활용 못함)

 

다양한 검색을 위한 추가적인 도움이 요구됨 

 

- 클러스터 인덱스의 부족함을 도와주는 비 클러스터인덱스가 필요 

 

힙 + 비 클러스터 형 인덱스 

 

비 클러스터 형 인덱스가 가진 것 

 

- 생성한 인덱스 키 열의 모든 데이터 

  name,age 컬럼으로 만들었다면 

  name,age + RID값을 가지고 있음 

 

RID

 

 힙 테이블이 데이터가 정렬되어 있지 

 않기 때문에 RID를 매칭시킴

 

RID를 갖는 이유 

 

- 주소를 딱 찍어주니 좋음 

- RID는 거의 변하지 않음 

- RID는 값이 크지도 않음 

 

비 클러스터 인덱스는 999개까지 만들 수 있음

 

- 불필요한 비 클러스터 인덱스를 너무 많이 만들면 성능 저하 

- 데이터와 별개로 저장되기 때문 

 

힙 + 비 클러스터 형 인덱스 

 

index Seek 

 

- Root페이지부터 찾아가기 

- 아주 빠른 성능을 보여 줌 

 

Rid Lookup 

 

- 힙 테이블을 찾아가는 과정

- 비 클러스터 형 인덱스가 가지 못한 데이터를 찾아가는 과정 

 

Index Scan

 

- 리프 수준의 모든 인덱스 페이지를 다 읽음 

 

총 정리 

 

- 비 클러스터 인덱스는 컬럼을 다 가지고 있지 않지만, 다 가지고 있을 수 있다.

 

- 쿼리는 빼가는 과정이다. 

  조회에 필요없는 컬럼을 제거 

  조회 화면을 변경

 

- 쿼리는 테이블이 아닌 인덱스로 날려야 한다 

  인덱스의 도움을 받지 못한 쿼리는 테이블로 날아가고 성능에 문제가 생길 수 있다. 

 

 

반응형

'IT > DB' 카테고리의 다른 글

tnsnames.ora 접속하는 방법  (0) 2021.10.26
오라클 클라이언트 및 패키지 설치 방법 (2021.10.26 기준)  (0) 2021.10.26
왜 데이터베이스 튜닝을 해야할까 ?? -  (0) 2021.10.14
쿼리란 ?  (0) 2021.10.14
DBMS와 SQL이란  (0) 2021.08.19
728x90
반응형

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

 

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

 

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

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

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

 

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

 

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

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

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

 

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

 

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

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

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

 

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

 

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

 

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

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

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

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

 

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

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

 

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

 

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

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

 

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

 

반응형
728x90
반응형

디비의 기본 쿼리란 ?? 

 

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

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

 

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

 

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

 

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

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

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

 

 

반응형
728x90
반응형

좀 늦은 21년 9월 배당금 내역이다..

10월초에 연휴가 껴있고..

 

야무지게 제주도를 다녀왔다 ~ !! 

 

9월 배당금으로 

화이자(제약) - 3.98

마소(빅테크) - 2.38

DIA(다우지수) - 0.52

리얼티인컴(리츠) - 3.2

AMAT(반도체장비) - 1.02

엔비디아(반도체) - 0.17

기업으로부터 배당금을 받았다.

총 11.27 

현 시각 원달러 환율 기준으로

13000원을 받았다..

 

요즘 공모주와 

다른 증권사에 시장 지수 ETF를 사놔서..

배당금을 더 받기 위한

작업을 못하고 있어서 아쉽다.

 

1억은 사모아서 달에 30만원 

이상은 받고 싶다.. 

 

 

반응형

+ Recent posts