[오라클] Network 성능 튜닝

SQL*net more data from/to client

---

SQL*net과 관련된 모든 대기 이벤트는 System API Call에서 비롯됨을 이해해야 합니다. 가령, SQL*net과 관련된 대표적인 대기 이벤트인 SQL*net message to client는 Server Process가 OS에서 Network Send API 요청을 하고 응답이 오기를 기다린다는 것을 의미합니다. OS는 Server Process가 요청한 Data를 TCP Send Buffer에 넣는 것으로 일을 마치고 Server Process에게 응답을 보냅니다. 즉, SQL*net message to client 대기는 실제 Network 전송이 끝나기를 기다린다는 의미가 아니라 OS가 Send Buffer에 성공적으로 Data를 등록하기를 기다린다는 것을 의미합니다. Network API들은 이런 속성을 지니고 있습니다.

{ 대기 이벤트 = System API Call }

위와 같은 명제를 기억해야 합니다.

"more" 수식어가 붙는 경우에는 Data의 전송량이 많아서 한번에 전송하지 않고 여러 번에 나누어서 한다는 것을 의미합니다. more이 붙은 경우에는 message가 아닌 "data"라는 용어가 사용됩니다. 가령, 아주 긴 SQL 문장을 Oracle에서 수행요청하는 경우 Oracle은 OS에 전송 요청을 하면 응답이 올 때까지 SQL*net more data from client 이벤트를 대기합니다. 거꾸로 아주 큰 Data를 Client에게 보내주어야 하는 경우(LOB가 대표적인 경우) Oracle은 SQL*net more data to client 이벤트를 대기하게 됩니다.

Common Causes and Actions

- 원인: 아주 큰 Data의 전송 과정에서 발생하는 Wait Event

- 진단 방법: Oracle이 대기하는 시간은 Client와의 통신이 아닌 Network API Call 수행시간임

- 개선 방법: SQL*net 류의 대기 이벤트는 Network 성능과는 직접적인 관련이 없다.

* SQL*net 류의 대기 이벤트 Mechanism

1. Client가 Server Process에 Data 요청을 한다.

2. Server Process는 Data를 Fetch 한 후 OS에서 Network Data 전송을 요청하고 OS로부터 응답이 올때까지 SQL*net message to client 이벤트를 대기한다. OS는 Oracle로 부터 받은 Data를 Send Buffer에 채우고 Oracle 에게 전송이 완료되었다는 응답을 보낸다. 이때 SQL*net message to client 이벤트에 대한 대기가 끝난다.

3. Server Process는 OS에게 Client로부터 전송된 Network Data를 요청하고 OS로부터 응답이 올때까지 SQL*net message from client 이벤트를 대기한다. OS는 Receive Buffer에 Client가 보낸 Data가 도착하면 Oraclke이 전송이 시작되었다는 것을 알린다. 이때 SQL*net message from client 이벤트에 대한 대기가 끝난다. Oracle은 전송받은 Client의 요청을 처리한다. 다시 2번으로 돌아간다.

SGA: allocation forcing component growth

---

SGA: allocation forcing component growth 이벤트는 Oracle 10g부터 발생하는 이벤트로써, ASSM(Automatic Shared Memory Management)을 통해 SGA의 영역을 자동관리되도록 설정했을때 발생합니다.

ASMM은 오라클 내부의 통계나, 각 영역별 사용률을 기반으로, 사용 DB에 가장 최적화된 구성을 함으로써, 메모리를 보다 효율적으로 사용할 수 있다는 장점이 있습니다.

하지만 DB의 사용률이 항상 일정하지 않다면 (낮에는 온라인 밤에는 배치, 마케팅 등 이벤트를 자주하는 DB) 당시 상황에 따라 SGA를 재설정해야 할 빈도가 높아지게 됩니다.

즉, ASMM에 의해 SGA의 구성을 변경하는 순간, 모든 세션은 SGA: allocation forcing component growth 대기 이벤트를 기다리게 되며, Active Session이 수직으로 상승하며 성능 문제로 이어지게 되는 경우가 대부분입니다.

따라서 DB의 사용률 편차가 크거나, 매우 중요한 DB라면 ASMM을 사용하지 않고 Manual로 사용하는 것이 좋습니다.

Common Causes and Actions

- 원인: ASMM 설정에서 SGA 사이즈 변경

- 진단 방법: SGA: allocation forcing component growth 이벤트가 발생하는지 확인한다.

- 개선 방법: ASMM을 사용을 정지하고 Manual하게 값을 지정하여 사용한다.

* DBA_HIST_SGASTAT의 활용

ASMM을 사용하지 않는다면 각 영역별 값을 수동으로 세팅을 해야 하는데, 적정 값을 구하기가 어려울 수 있습니다. 하지만 AWR에서 제공하는 DBA_HIST_SGASTAT을 이용하면, 어렵지 않게 값을 정할 수 있습니다. 이 View는 Snap ID별 각 component의 사이즈가 얼마였는지를 확인할 수 있습니다.

이를 기반으로 각 Component 별로, 최저 사용 값과 최고 사용 값을 고려해 Manual 하게 값을 지정할 수 있습니다.

Memory의 적정 값은 사이트 환경별로 다른 부분이 많이 공통적인 값을 정하기는 어렵습니다.

출처: https://12bme.tistory.com/338?category=749950 [길은 가면, 뒤에 있다.]