전체 글291 [Recovery]Log-based recovery log recored는 우선 buffer에 저장을 하게 된다. 적절한 시점이 되면 storage에 있는 log db에 저장하게 된다. 이 때 disk io단위는 block이고 log도 블락 단위로 저장이 된다. 버퍼가 꽉 차면 디스크에 써야하고 log force라면 commit시 저장을 하게 된다. 비용을 줄이기 위해 가급적 log 버퍼를 블락만큼 채워서 디스크에 써야 할 것이다. 로그 기록은 생성된 순서대로 저장이 되어야 한다. Ti가 commit state가 되려면 이 log db에 저장되어야 한다. Logging 트랜잭션이 정상적으로 수행될 떄 기록되는 로그를 살펴보자. Logging(during normal operation) : 트랜잭션이 시작될 때 : 업데이트가 될 때 : commit 될 때 .. 2020. 6. 4. [Recovery] Log 트랜잭션에 대한 정보를 로그로 남겨 두어야 failure에 대한 대비로 기록해둘 수 있다. 이 정보를 통해 복구할 수 있는 것이다. recovery approach 1. log-based recovery: write 연산을 수행하기 전에 로그를 stable storage에 남기는 방법이다. 2. shadow-paging: 데이터를 업데이트 하면 old page의 copy를 갖고 있는 것이다. 초기 db 에서 사용하였다. shadowing concurrent transaction 상황에서 쓰기 어렵다. seeking작업을 줄이기 위해서 이웃시키는게 좋은데 이 방법에서는 어렵다. 텍스트 에디터에서 사용한다. db 데이터를 업데이트하면 page를 추가하여 새로운 페이지에 업데이트하는 값을 쓰는 방식이다. be.. 2020. 6. 4. [Recovery]disk i/o disk i/o는 atomic해야한다. 데이터베이스는 disk에 저장되어있고 system buffer가 main memory에 위치한다. 트랜잭션도 ram에 위치하며 read()를 하면 디스크에 x가 있는 페이지를 읽어서 시스템 버퍼로 가져온다. 그 후 트랜잭션이 시스템 버퍼에 있는 x 데이터를 가져온다. 버퍼에 x가 있는 페이지가 있다면 안 가져와도 된다. write의 경우에도 똑같이 디스크에 있는 페이지를 찾아서 시스템 버퍼에 가져오고 나서 시스템 버퍼에 있는 페이지의 데이터를 변경하게 된다. 버퍼에 있는 페이지를 디스크에 쓰는 작업을 한다. 이것은 output이라고 한다. output작업은 write시 마다 하는 것은 아니고 버퍼가 꽉 찼을 때 제거 대상이 되거나 할 때 하는 식으로 한다. 이 때,.. 2020. 6. 3. [Recovery] Overview subtopic Failure and Recovery Logs : Failure에 대비하여 update에 대한 정보 남기는 것 Buffer Management Log-based Recovery ARIES Algorithm Remote Backup Systems Failure type Transaction failure: 내부적인 오류나 데드락이 발생할 경우 System failure(Crash): 컴퓨터가 꺼지거나 SW가 꺼지는 경우. 물리적인 페이지로 구성되는 시스템 버퍼에서 실제 DB를 업데이트 해주지 못한 상태로 손실이 되는 경우 Disk failure: disk 자체에 문제가 생기는 경우. consistency를 유지하고 atomicity와 Durability을 보장하기 위해서 Recoveory는.. 2020. 6. 3. 이전 1 ··· 34 35 36 37 38 39 40 ··· 73 다음
