Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

오라클은 빠른 캐시처리를 함에 동시에 장애발생에 대응하기위해 DB의 변경부의 스냅샷(로그)을 유지하려고 합니다.

Redo 스냅샷의 Log <> 스냅샷의  본질적 의미와 사용기술이 다를수있으나 

Redo Log 는 주로 100만분의1초의 변경도 감지하고 기록하는 고성능 CCTV라고하면

스냡샷은 주로 필요할때 찍는 백업의 용도로 쓰입니다.

여기서는 Redo Log  = 지속적인 변경부의 스냡샷이라고 해두겠습니다.

(Wha is the diffrence between a Redo log and Snapshot에서 더 세부적인 차이를 검색하실수 있습니다.)

물론 로그를 자주기록할때마다 성능은 희생됩니다. 성능과 안정성을 동시에 올리는것은 아주 어려운일입니다.

어플리케이션 개발자는?  대부부분의 DB이전의 처리를 메모리및 디스크에서 하고 있으며 , 우리가 가진 로컬 DISK를

낭비적일만큼 활용하지 못하고 있습니다. 어플리케이션이 중단되거나 ,메모리가 휘발될때에 대해 대응을 하지못하여

마지막 상태를 DB에 기록하지 못하는이상 완전및 부분 복구를 할수없다란 것입니다.

그리고 분산적으로 위치한 수많은 어플리케이션이 그러한 기록을 위해 DB를 혹사 시켜도 안될것입니다.

우리가 가진 로컬 DISK를 낭비적일만큼 활용하지 못하고 있으며 

필요하면 , 어플리케이션도 휘발성이 있는 메모리 복구와 관련된 스냅샷처리에대해 고민을 해야합니다.

그것이 보장이 된다면, 우리는 중요한 기능 DB에 뒤늦게 기록해도 상관없는 몇가지 서비스를 캐시화하여 고성능 처리로 전환할수 있을것입니다.

...

데몬이 존재합니다. 이것은 오라클이 장애가 발생할수 있다란것을 가정하고 모니터링시스템이

장애에대한 최선의 노력을 한다란 의미입니다. 


어플리케이션에 있어서도 동일한 목적으로

장애대처를 하기위한 기존 예외 핸들링에대한 문제점과 한계점을 인지하고

...