전체 글
-
[DB] 데이터베이스 버퍼데이터베이스 2021. 4. 25. 14:12
Buffer management(버퍼 관리) 데이터베이스 파일과 메인 메모리는 fixed-length 블럭으로 나뉘어져있음 데이터베이스 시스템은 memory와 disk의 블럭 연산을 최소화하도록 설계됨 (디스크의 접근 오버헤드가 크기 때문) Buffer manager : 데이터베이스 시스템 버퍼를 관리 버퍼 매니저의 역할 데이터 read 시 버퍼 내에 요청된 블럭이 있는지 확인 -> 있으면 넘겨줌 disk 에서 읽어옴 -> 버퍼가 가득 찼으면 victim block 을 선정 후 쫓아냄 victim block 이 write 된 적이 있는 dirty block 이면 write back 따라서 보통 read only block 을 선정 읽어와서 넘겨줌 Victim block 전략 LRU : Least Rece..
-
[DB] Recovery 로깅 방식데이터베이스 2021. 4. 25. 14:09
로깅 방식 로그는 stable storage 에 존재 작업을 성공적으로 마친 뒤 반드시 로그를 write 함 로그 : 트랜잭션 Ti 가 시작 : 트랜잭션 Ti 가 X 값을 V1에서 V2 로 write : 트랜잭션 Ti 가 commit 여러 트랜잭션이 동시에 실행되더라도 모든 트랜잭션은 하나의 디스크 버퍼와 로그를 공유함 앞으로는 Strict two-phase 기법을 기준으로 설명함 : Read 를 할 때 해당 정보는 commit 이 된 상태임을 보장 Checkpoint 트랜잭션의 로그를 남겨 Backward 방식으로 리커버리(Undo)하는 것은 좋으나 그 범위가 너무 큼 이 문제를 해결하기 위해 체크포인트 개념 도입 checkpoint 이후의 statement 만 redo 함 : L = 현재 active..
-
[DB] Recovery 기본 개념 + Shadow데이터베이스 2021. 4. 25. 14:02
Recovery Failure 분류 트랜잭션 실패 Logical error : 내부 조건의 문제 System error : 데드락 같은 시스템의 문제 시스템 실패 : 전원 문제 등 volatile storage(메인 메모리) 의 유실로 인한 문제 발생 Page -> Buffer-> Disk 순서로 write 되는데 버퍼는 메인 메모리에 저장되므로 시스템 문제로 유실되면 application 은 write 했다 생각하지만 실제 disk 에는 쓰이지 않는 문제 발생 (Durability 준수 X, Inconsistency 상태) 디스크 실패 예 Recovery 알고리즘은 ACID 를 만족해야하며 보통 로그를 이용함 Storage structure Volatile storage : 메인 메모리 Nonvolat..
-
[DB] Isolation데이터베이스 2021. 4. 25. 12:08
Isolation 트랜잭션은 DML을 만나면 암묵적으로 시작 명령어 set transaction commit rollback savepoint : abort 시 이 시점으로 돌아감 rollback to savepoint consistency vs performance Read-only 트랜잭션 : 대략적인 추정 결과를 내놓는 대신 성능을 향상시키는 방법을 사용 = Consistency level 이 낮음 Degree-two consistency Two-phase locking protocol 은 phase 2가 되어야 unlock 이 가능하지만 Degree-two consistency 는 S-lock 에 한하여 중간중간에도 unlock 이 가능 주로 Cursor 에 사용됨 = 읽을 때만 S-lock 을 ..
-
[DB] 팬텀현상데이터베이스 2021. 4. 24. 23:39
데이터의 입력과 삭제 insert, delete 모두 X-lock 을 얻어야 가능 Phantom phenomenon(팬텀 현상) : two-phase lock 을 써도 이상한 경우 팬텀 현상의 가장 큰 문제는 서로 다른 item 에 대한 연산에서 충돌이 발생한다는 것임 예 T1 : Account 테이블에서 부산의 모든 balance 의 합과 Assets의 부산의 값이 같은지 비교 T2 : Account 테이블에 tuple 을 추가하고, Assets 테이블 또한 수정 2PL 에서의 흐름 T1 : Read(Account[100], Account[200, Account[300]) // returns 1500 T2: insert(Account[400, Busan, 700]) T2 : read(Assets[Bus..
-
[DB] 데드락데이터베이스 2021. 4. 24. 23:23
데드락 Deadlock handling Timeout-based schemes 일정 시간이 지나도 응답이 없으면 해당 트랜잭션을 롤백하는 방법 -> 구현은 쉬우나 starvation 발생 적절한 시간 설정이 어려움 트랜잭션 수행 전에 모든 데이터의 lock 을 검사하여 방지 = 현실적으로 불가능 Wait-die / Wound-wait scheme 트랜잭션이 시작된 시간을 timestamp 로 삼고, 이를 기준으로 처리하는 기법 Wait-die scheme Non-preemtive approach (비선점형 방식) Ti -> Tj := Ti 가 Tj 가 선점한 자원에 lock 을 요청함 이런 상황일 때 Ti 가 Tj 보다 old -> Ti 가 wait young -> Ti 가 die Wound-wait s..
-
[DB] 동시성 제어데이터베이스 2021. 4. 24. 23:21
Concurrency control(동시성 제어) 데이터베이스가 동시성 제어를 하려면 conflict serializable 또는 view serializable 을 지원해야함 그리고 기왕이면 recoverable 하고 cascadeless 함을 지원하면 좋음 스케쥴을 실행한 뒤에 serializability 를 알게 되는 것은 너무 늦기 때문에 Concurrency control protocol 을 정의하고, 이대로 실행하면서 serializability, recoverable 을 체크함 이 규약을 실행시켜주는 존재 = Concurrency control Lock based protocol X-lock = 읽기/쓰기 모두 가능한 lock S-lock = 읽기만 가능한 lock Lock compatibi..
-
[DB] Recoverable데이터베이스 2021. 4. 24. 16:35
Recoverable schedules 트랜잭션 중 하나가 failure 발생 시 회복 가능한가? -> 값을 write 하는 트랜잭션은 반드시 값을 Read하는 트랜잭션보다 먼저 commit 되어야 함 위 조건을 만족한다면 해당 스케쥴은 recoverable 하다 라고 표현함 Cascading rollback undo 작업 : 트랜잭션이 시작되기 전 상태로 데이터 아이템을 돌려놓음 : 시스템 부하가 큼 모든 트랜잭션이 commit 되지 않은 상태임 T10 으로 인해 T11이, T11로 인해 T12까지 rollback 되는 현상 : Cascading rollback(연쇄 롤백) Cascadeless schedule (ACA, Avoid Cascading, Aborts) write 이후에 read만 하면 되..