DB10

• 

  Log-Based Recovery Log Block Buffering log recored는 우선 메인 메모리의 buffer에 저장을 하며, 적절한 시점이 되면 storage에 있는 log db에 저장하게 된다. 버퍼에 있는 로그 기록이 가득 찼거나, log force 연산이 실행될 때 stable storage 로 이동한다. Log Force 는 commit 을 할 때 stable storage에 쓴다. Group commit : log 버퍼를 블락만큼 채워서 한 번의 output 연산으로 디스크에 쓰면 I/O 비용을 줄일 수 있을 것이다. Logging rule 로그 레코드는 반드시 생성된 순서대로 저장되어야한다. -> undo, redo 를 위함 트랜잭션 Ti가 commit state가 되려면 이 먼저 log db에 저장되어야 한다.. DB 2022. 4. 21.

• 

  Logs Recovery approach - log-based recovery : write 연산을 수행하기 전에 로그를 stable storage에 남기는 방법이다. - shadow-paging : 더 이상 사용되지 않는 오래된 방식으로 데이터를 업데이트 하면 old page의 copy를 갖고 있는 것이다. Shadowing atomicity 와 durability 를 지원하는 아주 간단한 방법이다. concurrent transaction 상황에서는 너무 많은 shadow 가 존재하기 때문에 다루기가 어렵다. 또한 큰 데이터베이스에서는 매우 비효율적이다. -> 데이터 clustsering 이 불가능하다. 텍스트 에디터에서 유용하게 사용된다. 모든 업데이트는 데이터베이스의 shadow copy에서 이루어지며, .. DB 2022. 4. 21.

• 

  Failure and Recovery Failure Classification - Transaction failure Logical errors : 내부의 에러로 인해 트랜잭션이 완료하지 못한다. System errors : 데드락과 같은 시스템 에러 때문에 데이터베이스 시스템이 실행중인 트랜잭션을 종료해야 한다. - System failure 휘발성 저장장치(volatile storage)의 유실되었을 때 문제가 발생한다. 전원 문제나 하드웨어/소프트웨어 실패는 시스템의 충돌을 일으킨다. - Disk failure head 충돌이나, 유사한 disk 의 실패는 디스크 저장장치의 일부, 혹은 모든 부분에 영향을 미친다. 디스크 드라이브는 실패를 감지하기 위해 checksum 을 사용한다. ex) 트랜잭션 T 가 A계좌에서 B계좌로 $50 를.. DB 2022. 4. 21.

• 

  Insert and Delete Operations Insert and Delete Operations 원칙적으로, Insert와 Delete는 X-Lock을 가지고 수행되어야 한다. 그러나 tuple 을 Insert와 Delete하려고 할 때 Phantom 현상이 생길 수 있다. Phantom Phenomenon T1 : Account 테이블에서 부산의 모든 balance 의 합과 Assets의 부산의 값이 같은지 비교한다. T2 : Account 테이블에 tuple 을 추가하고, Assets 테이블 도 업데이트한다. Possible 2PL-based execution 여기서 T1 은 1500 (처음에 Account 의 Sum) 과 2200 (Assests 에서 읽은 값) 을 비교하여 둘이 다르다고 생각한다. 위 결과는 혹은 그 어떤 것과도 같지 않으므.. DB 2022. 4. 20.

• 

  Deadlock Deadlock 위와 같이 모든 트랜잭션이 다른 트랜잭션이 release 하기를 wait 하는 상황이면 deadlock 이다. Deadlock Handling Timeout-based Schemes 일정 시간이 지나도 응답이 없으면 해당 트랜잭션을 rollback -> 구현은 쉬우나 starvation 발생한다. -> 적절한 시간 설정이 어렵다. Deadlock prevention protocol 트랜잭션 수행 전에 모든 데이터에 lock 을 검사한다. 모든 데이터 아이템에 부분적인 순서를 두고, 트랜젝션이 아이템들을 이 순서에 따라 lock하도록 한다. (graph-based) Wait-die/Wound-wait Schemes deadlock을 방지하기위해 트랜잭션 timestamps를 사용한다. Wa.. DB 2022. 4. 20.

• 

  Multiple Granularity Locking Multiple Granularity Locking 다양한 사이즈의 data item 에 대해 lock 을 걸 수 있다. - Fine granularity 레코드 단위로 잘게 쪼개어 락을 관리 -> 동시성 증가, lock overhead 증가 - Coarse granularity 테이블처럼 큰 단위로 락을 관리 -> 동시성 감소, lock overhead 감소 Intention lock Modes 노드 N에 대해 Intention lock 을 건다는 것은 미래에 N의 하위 노드에 (S or X)락을 걸겠다는 것이다. Intention-shared(IS) : Intention Shared Lock Intention-exclusive(IX) : Intention Exclusive Lock (X or S lo.. DB 2022. 4. 20.

• 

  Lock-based Protocols Lock-based Protocols lock 이란 data item 에 동시 접근하는 것을 통제하기 위한 메커니즘이다. data item 은 두 가지 모드로 lock 될 수 있다. - exclusive (X) mode : 읽기/쓰기 모두 가능한 lock - shared (S) mode : 읽기만 가능한 lock 모두 S-lock인 경우에만 서로 다른 트랜잭션이 동시에 락을 얻을 수 있다. 트랜잭션은 요청이 승인된 후에만 실행될 수 있다. 즉, 트랜잭션이 어떤 item 에 대해 요청한 lock 이, 이미 그 아이템에 다른 트랜잭션에 의해 걸려있는 lock 과 compatible 하다면 승인될 것이다. 얼마든지 많은 트랜잭션은 item 에 대해 shared lock을 hold할 수 있다. 다만, 어떤 트랜.. DB 2022. 4. 20.

• 

  Recoverability Recoverable Schedules 동시에 실행중인 트랜잭션 중 하나에 failure 이 발생할 때의 영향을 고려해야 한다. Recoverable schedule - 트랜잭션 Tj 가 Ti 에 의해 Write 된 데이터를 읽는다면, Ti 가 commit 하기 이전에 Tj 가 먼저 commit 을 해야한다. -> 값을 write 하는 트랜잭션은 반드시 값을 Read하는 트랜잭션보다 먼저 commit 되어야 한다. T8 에서 rollback 이 일어나면, T8 이 commit 을 하기 전에 T9 가 먼저 commit 을 한 상태이므로 복구가능하지 않다. -> database inconsistent Cascading Rollbacks 하나의 트랜잭션이 failure 하게 된다면, 연속된 트랜잭션의 roll.. DB 2022. 4. 19.

• 

  Serializability Correct Execution 동시에 실행되는 트랜잭션들이 올바르기 위한 기준은 다음과 같다. 1. Conflict serializable 2. View serializable -> 트랜잭션의 직렬 수행은 항상 correct 하다. (data consistency 를 항상 보장받는다.) Nonserializable Execution - dirty read T2 는 dirty data 를 읽게 된다. (T1이 write 한 값을 읽게 됨) - lost update T2 가 A를 변경한 효과가 없어지게 된다. - unrepeatable read T1 이 서로 다른 A 를 읽게 된다. Schedules 여러 트랜잭션을 동시에 실행하기 위해서는, 순서를 스케줄링 해야 한다.이때 schedule 이 다음과 같은.. DB 2022. 4. 19.

• Transaction Transaction 데이터에 접근하고 데이터를 업데이트 시키는 데이터베이스 프로그램의 단위이다. 다음과 같은 이슈를 다뤄야 한다. - 하드웨어, 소프트웨어, 트랜잭션의 실패 - 여러 트랜잭션의 병행 실행 ACID 트랜잭션이 가져야 하는 4가지 특징이다. 1. Atomicity(원자성) 2. Consistency(일관성) 3. Isolation(독립성) 4. Durability(지속성) Atomicity 원자성은 트랜잭션이 DB에 모두 반영되거나, 전혀 반영되지 않거나를 뜻한다. -> All or Nothing Consistency 일관성은 트랜잭션이 실행된 후에도 데이터베이스가 일관성을 유지하는 것이다. - 명시적 일관성 : 기본키, 외래키 - 암묵적 일관성 : ex) A에서 B로 이체하는 경우, A+.. DB 2022. 4. 19.