만숭이의 블로그 :)

장애는 필연적으로 발생하기에 복구 시스템이 갖춰져야 한다. 질의처리기 - read/write -> 트랜잭션 매니저(for 직렬성, 일관성) # 실패의 분류 - 트랜잭션 실패 ˙ 논리적 에러 : 트랜잭션이 내부조건으로 인해 더 이상 정상적인 실행을 지속할 수 없다 ˙ 시스템 에러 : 교착상태 같은 상태에 도달하여 더 이상 정상적인 실행이 안된다. 그러나 이후 재실행될 수 있다 - 시스템 손상 ˙ 시스템을 중단시키지만 비휘발성 저장장치의 내용은 손상시키지 않는다는 가정을 실패 중지 가정 - 디스크 고장 ˙ 데이터 전송 작업동안 헤드의 손상이나 고장으로 인해 내용을 손실할 수 있다. 따라서 3차 저장 매체에 백업 - 복구 알고리즘 (데이터베이스의 일관성과 트랜잭션의 원자성을 보장하는 알고리즘) ˙ 로그(jou..

# Dead handling 교착상태 처리 - 트랜잭션이 서로 기다리는 상태 - 교착상태 예방 프로토콜은 교착상태에 절대 들어갈 수 없는 것을 보장한다. - 교착상태에 빠진 트랜잭션의 일부를 롤백시키는 과감한 조치 - 방법1 : 교착상태 예방 규약) 각 트랜잭션이 실행되기전에 데이터들을 미리 준비한다. (predeclaration), 데이터들의 접근 순서 등을 정한다 -> 세세하게 요구하기가 힘들다 - 방법2 : 교착상태 탐지 & 복구기법) 고유성 손실 부담이 있음 ## 교착상태 예방 액세스 기법 1) 락 요청 순서에 있어서 대기 사이클이 일어나지 않도록, 혹은 필요한 락을 한꺼번에 요청 - * 각 트랜잭션이 실행 전 필요한 모든 락을 요청 단점 : 트랜잭션이 시작하기 전 어떤 데이터 항목에 락이 걸려야..

- 한 트랜잭션이 락을 가지고 있는 동안에 다른 트랜잭션들은 락을 가질 수 없고 그 락이 해제될 때까지 기다려야 한다. 락킹 정책에 따라 한 순간에 단지 하나의 트랜잭션만 실행한다. 따라서 순차적 스케줄만 생성된다. - 직렬적이며 복구가능하며 비연쇄적임을 명백히 알 수 있다. - 트랜잭션에 의해 획득된 모든 락들은 그 트랜잭션이 커밋되거나 중단된 후에(abort) 전부 해제된다 충돌 직렬성 -> 락 기반 프로토콜로 구현 뷰 직렬성 -> 타임스탬프 기반 프로토콜로 구현 SQL -> 질의처리기 -> read/write 트랜잭션 -> 트랜잭션 매니저(여기서 lock request 명령어를 받음) -> 동시성 제어 컴포넌트 -> 스케줄 -> 직렬성 -> Lock Manage 충돌 발생 º 행렬값이 true일때는..

- 동시 수행한 스케줄의 결과가 트랜잭션을 하나씩 순차적으로 수행하는 스케줄의 실행 결과와 동일하도록 함으로써 데이터베이스의 일관성을 보장할 수 있다. ** 동시 수행 스케줄이 순차 스케줄과 동 등해야 한다 -> 직렬 스케줄 - 순차 스케줄은 반드시 직렬성을 갖는다. # Serializability 직렬성 - 충돌 직렬성 - 뷰 직렬성 - 동시에 수행해도 일관성을 유지할 수 있다는 것을 보장 # 충돌 발생하는 상황 - 만약 트랜잭션이 서로 다른 데이터 항목을 액세스 하는 경우에 다른 명령어들에 순서 주지 않고 두 명령어의 순서를 바꿀 수 있다. - 하지만 같은 데이터 항목을 액세스한다면 두 명령어의 순서는 중요한 문제가 될 수 있다. - 트랜잭션 순서에 따라 내용이 변하므로 충돌이 발생한다. - 충돌 발..

# Transaction 거래 - 하나의 논리적 작업 단위를 이루는 연산들의 집합 - 논리적인 작업의 단위 - 데이터베이스 무결성을 지키기 위해 존재 - DB시스템은 비일관성 상태가 되지 않도록 하면서 트랜잭션들의 동시 실행을 지원해야 한다. - 트랜잭션은 항상 일관성 있는 값을 만들어야 한다. ## 꼭 지켜야 하는 규칙 ACID !! # 송금의 경우 ** All or Nothing (성공적인 경우) ** - 1~6까지 잘 이루어짐 - 두 번의 업데이트 작업 (write)도 잘 이루어짐 ** Atomicity 원자성 ** - 4,5,6 이 실행되지 않으면 돈은 증발됨 -> 비일관적인 데이터베이스 상태 (실패 원인 : sw or hw) - 1,2,3 단계에서 실패하면 데이터베이스에 기록하면 안 됨 -> 아..

클러스터링인덱스 비클러스터링인덱스 희소 -> 클러스터링만 밀집 -> 클러스터링, 비클러스터링 희소 불가능 (pdf 11.2순서인덱스 10.9페이지~) # 인덱스 갱신 인덱스가 추가되면 검색키도 추가됨. 인덱스 삭제되면 검색키도 삭제됨 # 삽입 : 밀집 주인덱스(=클러스터링인덱스) 학과로 검색키를 만들었으며 클러스터링 인덱스이고, 학과 모두 반영 되어있으므로 밀집인덱스이다. 위 그림의 주 인덱스 상황은 중복을 허용한 인덱스로 밀집인덱스를 만든 상황 1) 검색키 값이 인덱스에 없을 경우 순서에 맞게 삽입 2) 동일한 검색키값을 가지는 데이터 레코드들 중 첫번째 레코드에 대한 포인터만 가지고 있다면 별도의 인덱스 수정이 불필요 # B+ 트리 동작 구조

인덱스의 목적은! 원하는 데이터에 신속하게 접근하기 위함. 주키와 후보키는 개체무결성제약조건(변경사항 관리) 외래키는 참조무결성제약조건(변경사항 관리) 즉, 값들에 대해 영향받음(데이터변경에 영향받음) 검색키는 다른키들과는 다르게 검색성능이 좋아야한다 -> 인덱스 생성 검색키는 값들에 영향을 받지 않고, 데이터 검색 성능에만 영향받음 하나의 테이블에 주키(primary key)는 하나여야함. 하지만 , 검색키들은 하나의 테이블에 여러개 존재할 수 있음. # 검색키 Search Key - 파일에서 원하는 레코드를 찾기 위한 칼럼들의 집합 - 하나의 테이블에 하나 이상의 검색키들이 존재할 수 있음 = 여러개의 인덱스들이 존재가능 # 인덱스 파일의 구성 엔트리 검색키 ("김갑동") 포인터 (해당 위치의 레코드..

테이블은 칼럼(열)과 로우(행)으로 구성되어 있다 -> 추상적인 개념. 파일로 가게되면 행이 레코드가 된다. 레코드는 여러개의 필드로 구성되어 있는데, 열이 레코드에서는 필드가 된다. # 파일 구성 방법 테이블은 레코드들의 집합 - 힙 파일 구조 : 공간이 있으면 배정 - 순차파일 구조 : 주어진 키 (검색키)값에 따라 연속적인 순서로 배정 검색하는것은 조건이 적용되는 것. 이때, 조건값이 검색키. 정렬은 검색/시행착오 과정을 줄여줌 - 해싱파일 구조 : 속성들을 해시함수에 적용하고 파일 내 위치를 정함. 시행착오 x ex 레코드 구성) "홍길동" | 컴공 | 2019 | 3.8 일 때, 예시의 레코드를 찾으려면 해시함수H("홍길동") 한다. H("홍길동")=57일때, 파일 내 57번째에는 홍길동의 레코..

데이터베이스는 많은 파일들로 구성됨. # 파일 - 디스크에 영구적으로 저장 - 레코드들의 논리적인 구조 -> 디스크의 블록에 대응 # 블록 ** 파일들이 읽고 쓰는 것은 블록단위로 수행됨. - 데이터 전송의 단위 (cpu와 디스크 사이에 파일을 주고받는 단위) **중요** 하나의 파일은 여러개의 블록으로 구성됨 블록의 크기는 고정됨 파일의 입출력 단위는 블록 하나의 블록은 여러개의 코드로 구성됨 코드가 블록을 초과할 수는 없음 한 개의 코드가 두 개 이상의 블록에 걸쳐서 존재할 수는 없음 # 고정길이 레코드 - 각 레코드는 53바이트로 고정 -> 레코드의 크기가 53이 아니면 레코드 낭비 - 삭제된 레코드를 나중의 삽입을 대비해 가만히 냅둔다. 새로운 데이터를 끼워만준다 (크기는 같으므로) - 고정된 길..

# MTTF = 평균 가동 시간 ## RAID (Redundant Array of Independent Disks) 많은 수의 디스크를 병렬화 데이터 중복화 가능 -> 저장의 신뢰성 향상 # 미러링 - RAID중복 - 모든 디스크마다 복사디스크를 마련함 - 논리적인 디스크 1개 = 물리적인 디스크 2개 (삭제포함 쓰기는 두 디스크 모두에서 이뤄짐) - 만약, 두 디스크의 MTTF가 겹치는 경우는 거의 발생하지 않는다 -> 신뢰성이 굉장히 높음 - 비용이 많이 소요됨 # 분산(Striping) - 여러 개의 디스크에 데이터를 분산 -> 병렬접근으로 전송속도 향상 - 디스크 배열을 하나의 논리적인 큰 디스크로 간주 1) 비트단위 분산 디스크 수가 8의 배수이므로 병렬처리르 통해 8배의 전송속도를 얻음. 2)..