EXADATA Developer - 8

EXADATA Developer - 8
> Exadata Smart Flash Cache Intelligent Caching: Overview
> Flash Cache는 사이즈가 고정되기 때문에, LRU 방식으로 메모리 관리 (Lease Recently Used)
> Using Exadata Smart Flash Cache: Write-Through Cache
  데이터 읽는 순서
  1. DB Buffer Cache
  2. Flash cache
  3. Hard Disk
  Write시 디스크에 먼저 씀
> Usgin Exadata Smart Flash Cache: Write-Back Cache
  Write할 때 Flash에 먼저 씀. LRU 기반이니, 최신 데이터는 Flash Cache에 있음.
  - Primary와 Mirror가 있을 때, Read는 Primary를 읽고, Write는 Primary와 Mirror 모두.
  - 그럼 Write-Back 모드에서 Flash가 깨지면? (하드 디스크가 깨지면 Mirror가 있으니 괜찮음)
  - 따라서 Write-Back일 때는 Mirror가 있는 다른 Cell의 Flash에도 Write.
> free buffer waits
  - DB Buffer 상태
  1. dirty : 데이터를 DB Buffer에 읽었는데, 변경된 상태. (deferred write 때문에 디스크 파일에 변경이 되지 않는 상태)
  2. pinned : 지금 acces 중인 상태
  3. free : free인 상태.
  - free buffer를 확보하기 위해서 db buffer cache에서 dirty 상태인 buffer들을 Disk에 write함. 이 작업을 위해 대기가 일어남 => free buffer waits
> Columnar Flash Caching
> Exadata Smart Flash Log: Overview
  - SGA에 log buffer가 있고, commit이 발생하면 LGW이라는 bgprocess가 redo log file에 write
  - 근데 LGW가 해주는 작업이 SYNC I/O임. (AWK를 받아야 다음꺼 Write)
  - 그래서 동시에 Smart Flash Log라는 것이 있어서, Flash도 같이 write하고, 먼저 Awk 오면 다음꺼 Write함. 그럼 redo log file과 flash log의 차이는 flash가 맞춰줌.
  -> log file sync라는 wait event를 해결하기 위한 방안!

 

  1. Read Request가 발생하면, 먼저 DB Buffer 확인.

  2. 없으면, Flash Memory에 있는 지 확인.

  3. 없으면, Hard Disk에서 Read하고, DB Server로 결과 Return 후, Flash Memory에 해당 Data Write (LRU 방식으로 운영)

 

 

 

1. Read Request가 발생하면, 먼저 DB Buffer 확인

2. 없으면 Flash Memory에 있는 지 확인. 있어서, 결과 Return