|
|
|
![]()
| [일반] [오라클튜닝] BIND 변수를 사용한 쿼리문 구성 |
|
| 호석 님께서 쓴 글입니다 - 211.♡.74.31 |
읽음:5413 |
|
|
BIND 변수를 사용하지 않았기 때문입니다. BIND 변수를 사용하지 않으면 오라클의 경우 모두 서로 다른 SQL로 판단하여 매번 하드 파싱을 하여야 합니다. CPU 과부하나 동시접속이 많을 경우 성능을 엄청나게 저해하게 됩니다. 동시접속을 증가시켜가면서 시뮬레이션을 해보시기 바랍니다. BIND변수 유무에 따른 엄청난 결과를 목격할 수 있습니다.
그냥 Shared pool을 막연히 늘리는 것은 전형적인 밑빠진 독에 물붓기식으로 아무 도움이 되지 않을 뿐더러 오히려 상황이 악화될 수 있습니다.
제가 지끔껏 오라클 접하면서 느꼈던건...웬만한 규모 사이트의 경우 100메가 많아봐야 200M안쪽의 Shared pool이면 충분했습니다. 물론 BIND변수를 잘 활용했다는 전제하에...
대형 시스템이라도 500M가 넘어간다면 심각하게 고민해봐야 할 겁니다. 어떤 대형 쇼핑몰은 끝까지 BIND변수 Guide를 따르지 않고 1G까지 늘린 것도 봤습니다. 1G까지 늘려도 전혀 성능이나 Hit Ratio등은 개선되지 않았고.. ora-4031 에러도 여전했습니다. 동시접속에 따른 하드 파싱 부하는 CPU를 엄청나게 꽂아서 해결하고 있었습니다. 그 사이트는 오히려 더 대형 시스템을 구매하는 방향으로 가닥을 잡았습니다. 정말 어리석은 짓이죠.
만약 회원 로그인 인증하는 SQL이라고 생각해봅시다.
(1) select * from member where userid='홍길동' and passwd = '암호'
(2) select * from member where userid=:name and passwd = :passwd
1번 처럼 짰다면 만약 하루에 2만명이 로그인하는 사이트라면 로그인할 때마다 2만개의 서로 다른 SQL로 판단하여 각기 Shared pool을 점유할 뿐더러 매번 하드파싱을 해야하므로 부하를 심각하게 주게 됩니다. 2번으로 짰다면 단 한번만 파싱해서 그 결과를 자손대대로 공유해서 쓸 수 있습니다.
그리고 커서는 귀중한 자원입니다. 쿼리 한번 실행하고 close로 닫아버릴게 아니라 계속 재활용할 방안을 강구하고 코딩 스타일을 그렇게 길들여야 합니다.
표층으로 드러나는 현상을 보고 치료하지 마시고... 현상의 근본원인을 찾아서 치료하는게 더 중요합니다. 빙산의 드러난 부분만 보고 Shared pool을 무조건 늘리고보는 방식은 이제 지양해야할 시점이 아닌가 싶네요. (늘려봐야 큰 효과 없다에 걸겠습니다.)
|
|
|
|
|
|
