채니의 mimimimamimimo 블로그

What? 여러 개의 쿼리를 하나의 작업 단위로 묶은 것. (mysql에선 start transaction~commit까지임)

ACID 성질을 만족함

-Atomicity(원자성): all or nothing (아래의 why 참고)

-Consistency(일관성): 기본키 외래키 제약 조건 등이 어떤 커넥션에서든 조건이 동일해야 한다

-Isolation(독립성): 복수의 트랜잭션이 순서대로 실행되는 경우와 같은 결과를 얻을 수 있어야 한다.

ex) 방 10개 중, a와 b가 같은 화면을 보고 동시에 예약하면 2개 빼져야하는데 고립성 보장 안되면 1개만 빠짐.

직렬화 기능을 제공하여 격리수준을 더티읽기(a가 커밋 안했어도 9개로 읽음)~애매한 읽기(1회결과=?2회결과)로 조절 가능하다.

-Durability(지속성): 성공적으로 커밋되고 나면 하드웨어적or소프트웨어적 문제 발생해도 보존되어야 한다. 

트랜잭션 관리를 잘 해야한다!

Why? 하나의 단위인데 그 안에서 A 수정 후 B 수정인데 B가 not null 조건에 위배된다면

이미 수행된 A를 어떻게 하느냐, 이런 것을 처리하기 때문이다.

issue!

제약 조건 위배->사용자 요청으로 철회되는 상태

교착상태, 타임아웃->DBMS가 철회

아무 문제 없음->커밋된다

+교착상태: 서로 잠금을 건 자원에 잠금이 필요한 처리. 아무리 기다려도 바뀌지 않는 상태-> 트랜잭션을 자주 커밋해서 작은 단위로 쪼개서 교착상태의 가능성을 낮춰서 해결할 수도 있다.

+데이터베이스 시스템 구조

(질의처리기  |   (페이지버퍼) 저장시스템 )

DBMS는 데이터를 디스크에 저장하고, 일부는 메인 메모리에 유지한다. 저장의 단위는 페이지. 

여기서 페이지버퍼를 관리하는 버퍼관리자의 역할이 중요하다!

버퍼교체알고리즘에 의해 커밋이 완료되지 않았지만 수정된 페이지를 디스크로 보내버릴 수가 있기 때문이다.(isssue 세번째에 해당하는거지) 보내기 전에 UNDO를 해줘야한다.  

UNDO: 완료되지 않았지만 일부 수정된 페이지를 원상복구

대부분 RDBMS는 언제든지 디스크에 수정된 페이지를 쓸 수 있도록 허용하기 때문에 UNDO는 필연적이다.

이전의 이미지로 현재 이미지를 대체

REDO: 커밋한 트랜잭션의 수정을 재반영하는 복구

대부분 RDBMS는 수정한 페이지를 커밋시점에 바로 디스크에 반영하지 않기 때문에 REDO는 필연적이다.

이후 이미지를 반영

UNDO와 REDO를 하는 법->LOG를 이용! 

LOG: DBMS의 모든 변경사항을 기록하는 레코드들이다. 변경 이전의 이미지와 이후의 이미지를 모두 가지고 있다. 

복구작업에 활용되므로 매우 안전하게 보관되어야 한다. 그래서 느린 함수를 쓴다.

issue! 로그쓰기(commit operation)의 성능을 높이는 법? 

그룹 커밋 대기시간을 잘 정해서 한꺼번에 처리한다. 디스크 출력 횟수가 줄어들기 때문에 속도가 빨라진다.

결론: 어차피 DBMS가 알아서 동시에 하면 하나는 롤백해서 교착상태 처리하는데 왜 알아야하냐면,

DBMS마다 정책에 약간씩 다르고 성능이 안좋을때 그 원인과 대처(로그성능,교착횟수)를 할 수 있다.

또한, 로그보존의 중요성을 알아서 사고를 예방한다. 

목표:

내 노트북에 오라클 서버를 설치하고 넣은 데이터를 멀리 떨어진 팀원이 데이터 조회가 가능하도록 만들기.

상황:

내 노트북에 오라클 설치를 먼저 했고, 간단한 데이터 입력 및 조회가 되는 것까지 확인.

팀원 노트북에서도 같은 과정을 수행.

문제:

원격접속을 하려고 할 때 no listener란 error가 발생하거나 network adapter를 찾을 수 없다는 error가 발생함.

원인:

사설IP를 사용하면서 포트포워딩 없이 노트북의 포트에 접근하려고 시도해서 서버를 찾을 수가 없었다.

사설IP,공인IP,유동IP,고정IP의 개념이해가 부족했다.

해결:

1. 포트포워딩orDMZ를 한다

2. aws를 사용한다(1도 성공하긴 했지만, 집 컴퓨터를 서버로 내내 돌리기에는 유동ip 성격상 ip가 바뀌거나, 컴퓨터가 꺼질 상황을 염려하여 aws를 사용하기로 했다.)

해결하게 된 추론:

1. 호스트 접속시 error: no listener.

2. 각 컴퓨터 listener 켜져있는지 services.msc로 확인

3.listener파일이 제대로 설정되어 있는지 확인

4.ping test로 각 컴퓨터 연결되는지 확인

이때,listener 파일에 있는 ip와 ping test가 가능한 ip가 다른걸 보고 사설ip와 공인ip의 차이를 알게 되었다.

5.공인ip와 사설ip를 연결해주는 방법, 포트포워딩을 찾게 되었다.

6.포트포워딩보다 간단한 DMZ 설정을 해보았다.

7. 다시 시도, 해결!

공부한 내용:

IP는 컴퓨터의 주소라고 할 수 있다. 아파트에 비유하자면, 부산광역시 해운대구 우동 00 센텀0로 00,00동 0000호라는 주소가 있다고 치자. 여기서,  공인IP는 '부산~~00로00'까지이다. 사설IP는 '00동 0000호'이다. 원격접속을 위해서 쳐야할 주소란에 나는 00,0000로만 계속 알려준 것이다. 친구에게 찾아와라고 자기 집 주소를 알려줄 때, 어느동네 무슨아파트인지 얘기도 안해주고 00동 0000호라고만 얘기하면 어떻게 찾아올 수 있을까?

네이버에 '내ip'를 검색해서 나온 ip는 공인ip이고 ipconfig로 검색해서 본 wifi ipv4는 사설ip이다.

그렇다고 공인ip만 알면 되는건 아니다. 공유기(NAT)까지만 찾아올 수 있고, 내 컴퓨터까지 도달할 수 없다면 소용이 없다.

이때 필요한 것이 '포트포워딩'이다. 위 그림에서 (C)에서 (A)의 1521포트로 접속하기 위해서 (A)와 연결된 공유기에 

"1521포트를 요청하면 A컴퓨터의 1521포트로 연결해줘"라고 설정하는 것이다. 방법은 생각보다 간단하므로 검색해서 찾아보면 된다. (자신 공인아이피로 접속을 하면 관리자 페이지가 뜨는데, 거기서 매핑을 해주면 된다. 모든 포트를 열어버려서 더 간단한 DMZ도 있으니 참고하자)

+고정IP란? ISP에서 제공받아서 특정 컴퓨터(기기의 MAC주소로)와 1:1로 매칭되는 IP. 즉, 사설IP고 뭐고 하나의 IP만 알면 세계 어디서든 접속이 가능하다. 유지비용이 비싸고,  IP가 바뀌면 안되는 기업의 서버 설치에 사용된다. 그래서 도메인 서비스가 가능하다. 111.111.111.111->채니.com 요렇게

+유동IP란? ISP가 특정 대역을 가지고 있어서, 그 대역에 한해서 사용자에게 IP를 자동으로 뿌려주는 것. 즉, 하나의 IP에 대해 사용자가 계속 바뀐다는 것이다. 

그 이후...

사용자이름,비밀번호 <-서버에서 생성한 아이디와 비밀번호

호스트이름 <-접속할 IP 

포트 <-oracle은 보통 1521포트를 사용함.

SID <- 접속할 DB의 인스턴스 이름

이렇게 접속을 만들기 전에 tnsnames.ora 파일과 listener파일을 따로 설정해줘야한다. 오라클에서 네트워크를 통해 원격접속을 하려면 오라클 폴더의 설정파일을 수정해줘야하기 때문이다. (->https://oracle.tistory.com/87) 그 다음 DBlink를 설정해주면 DB를 공유할 수 있다!

+여담: 성공하긴 했지만, 집 컴퓨터를 서버로 내내 돌리기에는 유동ip 성격상 ip가 바뀌거나, 컴퓨터가 꺼질 상황을 염려하여 aws를 사용하기로 했다. aws를 사용하며 사용자ID만큼은 다르게 하려고 했지만, 이또한 dblink가 필요하고 이를 위해서 클라이언트+서버 프로그램 둘다 설치해야하기 때문에 아이디를 하나로 통일하기로 결정했다.

+그 외에 알게된 것..

더보기

+ftp(21). ssh(22),web(80),oracle(1521)..

+ping테스트로는 해당 주소가 네트워크에 연결되있는지만 확인 가능하지만 별도의 프로그램 설치를 통해 

tnsping을 이용하면 특정포트가 열려있는지까지 확인이 가능하다. 

+오라클xe설치로 서버를 먼저 설치하고 클라이언트 앱으로 sqldeveloper를 깔아서 쓰는 것이다. 

내장된 sqlplus 클라이언트도 있다.

http://blog.naver.com/PostView.nhn?blogId=jyc8618&logNo=220163994820

 

+서버를 이전하는 것= 마이그레이션

인덱스란?

검색연산을 빠르게 하기 위한 Key-Value자료구조이다.

ex)n개의 데이터가 저장되있을때, 특정 값 찾으려면 n개의 데이터 모두를 검색해야한다. 하지만, 값_value을 정렬하여 순서_key를 붙여두면 값을 찾을떄 순서를 이용해 바로 접근해서 모든 데이터를 확인하지 않아도 되므로 빠르다.

종류

-B-TREE(트리형태로 key-value를 저장) 

-BITMAP(2차원 배열로 key-value를 저장) 

생성과정

전체 테이블 스캔->정렬->Block에 기록

1)B-TREE

+키,로우

위를 보면 알 수 있듯이/

-best

칼럼이 추가되도 B-TREE를 저장해뒀으므로 새로 정렬이 일어나지 않으므로/ 실시간 처리에 효율적이다(거진logn)

-worst

하나의 리프블록의 중간값이 입력되면 split이 일어나므로/칼럼 값의 수정이 빈번하지 않은 곳에 쓴다.(trie떄 생각하자..)

2)BITMAP

+함수지원으로 실제 로우주소 몰라도 상대주소로 계산이 가능

+1이 있는 값만 찾으면 된다

+키,로우스타트,로우엔드,비트맵

위를 보면 알 수 있듯이/

-best

비트연산을 사용하므로 빠르고 실제 칼럼값을 가지고 있지 않아도 되서 저장공간이 절약되므로/대량의 데이터를 한꺼번에 처리할 때 효율적이다.

-worst

칼럼 하나 추가되면 모든 테이블 바뀌어야므로 효율이 나빠지므로/ 맵의 칼럼 종류 수정이 적은 곳이 좋다.

..흠..이분법적으로 뭐는 시간이 좋고 뭐는 공간이 나쁘다 할 수 있는게 아니라 여로 요소를 생각해야하는구나

조회과정

사용자의 요청에 의해 서버프로세스가 메모리의 데이터베이스 버퍼캐시를 본다.

없으면 하드디스크의 데이터파일에서 data블록을 찾아 버퍼 캐시로 복사하고 사용자에게 값을 반환한다.

실습~~

CAP관련 설명

https://www.slipp.net/wiki/pages/viewpage.action?pageId=19530140

*아이패드로 정리한 pdf 파일*

참고) 데이터베이스 첫걸음, 기무라 메이지

정규형

칼럼을 정할 때 이상이 생기지 않도록 만드는 규칙

정규화

정규형을 만족하도록 릴레이션을 분해해나가는 것

아노말리

-삭제이상
200번학생이‘C123’ 과목을등록취소..200번학생의학년정보소실
-삽입이상
600번학생이2학년정보(투플)을삽입..불필요한정보(임시과목번호)를채워줘야함
-갱신이상
400번학생의학년을4->3로변경..4개의투플을모두갱신해야함

함수 종속

릴레이션이 변경되도 계속 지켜져야하는 의미적 관계(한 순간의 값으로 판단ㄴㄴ)

x(결정자)->y(종속자)

제1정규형: 하나의 셸에 복합적인 값을 포함하지 않는다

why? x에는 y가 대응하는 함수관계이기 때문에 기본키가 모든 열의 값을 하나로 특정할 수 있어야한다.

(1)처럼 칼럼을 추가->릴레이션 정의 변동이 많이 일어나서 성능 저하가 심함.

(2)->딩동댕

제2정규형: 제1을 만족하고, 기본키의 일부에만 종속하는 열이 없어야 한다 (==부분종속이 없어야한다)(기본키가 열이 하나라면 자동적으로 만족) 

why? 아래를 먼저 보자.

-기본키

cb,cb,cb가 중복되므로 [기업ID]만으론 기본키가 될 수 없다. 즉, [기업ID+주문번호]이다.

기본키를 정할 떈 의미적으로 거르고, 값으로 걸러서 정해야한다.

-존재하는 함수종속

[기업ID+주문번호]->[접수일]

[기업ID+주문번호]->[기업명]

[기업ID+주문번호]->[기업규모]

[기업ID]->[기업명]

[기업ID]->[기업규모]

여기서, 기본키의 일부인 [기업ID]에 종속되는 종속자 [기업명],[기업규모]가 있다. 

[기업명]과 [기업규모]열의 입장에서 보면, [주문번호]열음 쓸데없는 정보일 뿐이다. 

[주문번호] 열의 입장에서 보면, [기업규모]를 알지 못하면 데이터를 삽입할 수 없는 삽입이상이 생긴다. null허용은 썩 좋은 방법은 아니다.

그러므로, 기업ID만으로 기업명과 기업규모를 결정짓는 릴레이션으로  분해한다.

제3정규형: 제2를 만족하고, 기본키를 제외한 열에서 이행종속이 존재하지 않는다.

이행종속

기본키가 [a]일때, [b]->[c]라는 종속관계가 있으면 기본키 정의때문에 [a]->[b]가 성립되고, [a]->[b]->[c]가 되므로

[c]는 기본키[a]에 이행종속이다.

why?갱신이상이 여전히 존재하므로(참고로, 몇 정규화를 하면 무슨 이상은 완벽히 없어지고, 그런 경우는 없다. 단계가 높아질수록 이상이 생길 확률이 줄어드는 것 뿐이다). 아래를 보자.

거래가 발생하지 않으면 기업의 업계코드와 업계명을 추가하고 싶어도 추가할 수 없다.

(ex거래한 업계는 석유,바이오와 했는데 업계종류를 화학도 추가하고 싶을떄..)

이런 경우, 업계코드와 업계명을 따로 빼서 분해한다.

주의 와 같은 경우는 이행종속이 아니다. 해당 종속관계의 종속자가 기본키이므로 제3정규형 정의와 관련없다.

BCNF: 릴레이션의 결정자가 모두 후보키여야만 한다

-존재하는 함수종속

[학번+과목]->[교수]

[교수]->[과목]

결정자는  [학번+과목],[교수] 총 두 가지가 존재한다.

[학번+과목]은 기본키이므로 후보키가 아니다.

[교수]는 키가 아니다. 그러므로 BCNF를 만족하지 않는다.

*제3을 만족하지 않는다고 실수할 수 있다. 교수와 과목은 이행종속이 아니다. 과목이 기본키이므로, 제3의 정의인 '기본키가 아닌 열이 기본키로부터 종속자'에 해당하지 않기 떄문이다. 

정규화를 많이 하면 테이블 수가 늘어난다

->테이블 간의 관계성을 파악하기 힘들다

->ER다이어그램을 그린다.

정규화를 많이하면 테이블 수가 늘어난다

->조인을 할 확률이 높다

->성능이 낮아진다/대신, 아노말리는 적다

제5정규화까지 있지만 실무에선 제3정규화까지만 하면 된다

키의 종류와 관계