database.sarang.net
UserID
Passwd
Database
DBMS
MySQL
PostgreSQL
Firebird
ㆍOracle
Informix
Sybase
MS-SQL
DB2
Cache
CUBRID
LDAP
ALTIBASE
Tibero
DB 문서들
스터디
Community
공지사항
자유게시판
구인|구직
DSN 갤러리
도움주신분들
Admin
운영게시판
최근게시물
Oracle Q&A 21068 게시물 읽기
No. 21068
shared_pool 메모리 사용량
작성자
로그파일
작성일
2004-12-15 12:07:41
조회수
5,678

현재 shared_pool 메모리 사용량을 알수 있는 쿼리문이 있나요?

 

shared_pool_size 수정후 확인시 shared_pool 메모리 전, 후 사항을

 

알수 있는 쿼리문 알수 있을까요?

이 글에 대한 댓글이 총 7건 있습니다.

아까 글을 올리신 분이군요.. ^^

 

ora-4031 의 경우 아까 말씀 드린 대로 shared pool 내에 메모리 조각화에 따라서 연속된 parsing 공간을 제공하지 못하기 때문에..

parsing 에러가 발생하는 겁니다.

 

이를 해소 해주기 위한 방법으로 개체가 큰 자주 사용되는 프로시져등을 메모리에 pined 해주면 되며, shared pool 사이즈를 늘려 주는것이 가장 좋으며, 상황이 여의치 않는 경우 단편화된 shared pool 의 조각화을 다시 flush 해주는 방법등이 있습니다.

 

 alter system flush shared_pool;

 

 shared pool 의 hit 율을 잘 분석해 보시고 오라클의 권장사항에 따라서 튜닝 가이드 라인을 정하세요...

너무 크게 줘서 free size 가 너무 많이 남는 경우 즉 hit 율은 좋은데 ,

free size 가 너무 큰 경우는 메모리 낭비를 하게 되며, 각각의 o/s 에 따라서  paging 이나 swap 이 발생할 가능성이 있으니, 튜닝후 적적할 모니터를 통해서 사이즈를 잡아 가는 것이 좋습니다.

 

뭐 튜닝 툴(오렌지나 토드)을 이용하면 실시간적인 hit 율 및 free size 를 모니터 할수 있습니다.

 

위에 보이는 shared pool 의 hit 율 계산은 평균치 이므로 current 한 분석이 될수 없습니다.

 

 즉 오라클의 동적 뷰들의 대부분은 current 한 내용이 아닌 축적용으로 평균치를 나타 내기 때문에 의미가 없습니다.

 

 수고하세요... ^^

 

 

나그네님이 2004-12-15 13:34:44에 작성한 댓글입니다. Edit

제온cpu에 디비와 웹서버를 따로 사용하고

 

각각 2기가 메모리를 사용하는데요..

 

현재 shared_pool_size = 52,428,800 인데요

 

225,000,000 이정도로 늘릴생각인데. 적당한 size적용인건가요?

 

아..그리고.. 답변 감사 합니다.. ^^;;

로그파일님이 2004-12-15 13:49:20에 작성한 댓글입니다.
이 댓글은 2004-12-15 13:50:01에 마지막으로 수정되었습니다. Edit

이 부분은 직접 모니터 해야 알수 있는 내용입니다.

아까도 말씀 드렸다 시피, 오라클 튜닝 툴등을 통해서

peak time 시간 및 기타 사용 시간을 기준으로 실시간

shared pool 의 hit 율을 분석하셔야 합니다.

 

hit 율이 대부분 95% 이상은 나와야 되며, free size 도

모니터 하셔서 적합한 수치를 잡아 가는 작업을 하셔야 합니다.

어느 정도 사이즈냐는 해당 사이트 마다 사용에 대한 내용이

다르므로 이 부분은 가이드 해 드리기가 좀 어렵네요.. ^^;;

 

 수고하세요....

나그네님이 2004-12-15 14:00:37에 작성한 댓글입니다. Edit

ora-4031 에러나 Shared pool의 Hit Ratio가 떨어지는 현상... Latch Free 등에 Wait가 많이 걸리는것 모든게...

 

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을 무조건 늘리고보는 방식은 이제 지양해야할 시점이 아닌가 싶네요. (늘려봐야 큰 효과 없다에 걸겠습니다.)

김주현님이 2004-12-15 15:54:39에 작성한 댓글입니다.
이 댓글은 2004-12-15 16:08:21에 마지막으로 수정되었습니다. Edit

김주현님 말씀은 맞습니다.

하지만 이미 시스템이 괘도에 오른 상태에서 모든 어플리케이션을

리터럴에서 바인드 변수로 바꿀수는 없는 일이죠.....

 

다음에 추가될 어플리케이션 부터 적용하여, 차츰 어플리케이션을  수정해 나가야 할 것입니다.

 

하지만 지금 현실에 그렇지 못한 사이트는 정말 많습니다. ^^;;

 

일단 당장은 모든 어플리케이션을 수정할수는 없는 일이므로 .... ^^

 

 윗분의 질문에 대한 답변에 해결책을 제시하는데 있어서

 shared pool을 일단 증가 시켜줄 것과 shared pool 의 flush 가 상황에 따라서 필요할 거 같네요... ^^;;

 

 물론 김주현님이 말씀하신 내용은 지당합니다. ^^;;

 

 많이 배우고 있습니다. 감사합니다.

수고하세요...

 

 

나그네님이 2004-12-15 17:42:06에 작성한 댓글입니다. Edit

개발자들의 현실적 저항 물론 경험하죠.

 

거의 모든 컨설턴트들 심지어 유명한 사람들도 저항에 부딪힌다고 합니다. 물론 잘못 작성된걸 하루 아침에 다 고칠 수는 없지만 일단 그것이 문제로 지적되었으면 하루라도 빨리 고쳐나가는게 답이겠죠.

(종기가 곪았으면 짜내거나 외부 수술을 하여 제거하여야 합니다. 아프다고 놔두면 나중에 문제가 더 커지죠.)

미봉책으로는 문제가 해결 될 수가 없기 때문입니다.

 

일단 개발자들에게 시뮬레이션으로 BIND변수 미사용에 따른 오버헤드와 확장성의 제한을 보여주시기 바랍니다. 몸소 체험하게 하고 고쳤을 경우의 잇점을 설득하셔야 합니다.

 

그리고 가장 심각하게 영향을 주는 SQL을 (하드 파싱을 과도하게 일으키는...) Library cache를 추출하여 끄집어낼 수가 있습니다.

일단 그 SQL부터(심각한 것들부터) 하나하나 고쳐나가야 합니다.

(테스트 환경을 별도로 구축하고 지금 당장 시작해야 합니다. 아무리 본수가 많다고 하더라도 한달 정도만 하루에 1-2시간 투자하면 고칠 수 있습니다.)

 

또 하나 INSERT의 경우는 당장 BIND로 전환하더라도 WHERE 조건절이 없으므로 플랜이 변해서 성능상의 문제를 겪거나 하지 않습니다.

특히 루프를 돌면서 BIND변수를 사용하지 않고 INSERT하는 구문을 많이 보게 되는게 이게 정말 심각하게 만드는 것들입니다.

 

위의 전환은 반드시 격리된 환경에서 하시기 바랍니다.

BIND 변수 사용시 히스토그램 정보를 활용못하므로 플랜이 부정확하게 나올 수도 있기 때문이죠. CBO 방식의 옵티마이져를 사용하는 실재 서버에서 기존에 개발된 것들은 고치면 갑자기 느려질 수도 있습니다. 그러니 반드시 테스트 환경을 구축하시고 성능을 체크하면서 진행하시기 바랍니다. (trace를 뜨면서 진행하면 정확하겠죠.)

 

 

 

정말 이해안가는 것 중에 하나가... 이런 정작 중요한 문제들은 모두 건너뛰고 자료형을 char로 해야 빠르다거나... 제약조건을 걸지 말아야한다거나, 익스텐츠가 100가 넘어가서 Reorganize를 해야겠다거나  이런 이상한 문제를 고민하고 계시더군요.

 

제가 프로젝트 들어간다면 제일 먼저 체크하는게 저 BIND변수를 쓰느냐일겁니다. 제일 중요한 이슈 중에 하나죠. ^^;

김주현님이 2004-12-15 18:08:51에 작성한 댓글입니다.
이 댓글은 2004-12-15 18:15:39에 마지막으로 수정되었습니다. Edit
[Top]
No.
제목
작성자
작성일
조회
21071sql*loader 관련 [1]
궁금이
2004-12-15
1883
21070Oracle 7.3.2.2.1 클라이언트 설치가 안됩니다.(읽어주세요 [3]
kami
2004-12-15
1221
21069SQL PLUS접속시 애러가납니다. [3]
kami
2004-12-15
1361
21068shared_pool 메모리 사용량 [7]
로그파일
2004-12-15
5678
21067ORA_00604 에러 [1]
초보
2004-12-15
3590
21066그룹 합계에 관하여 질문드립니다. [4]
이진홍
2004-12-15
1720
21065테이블 스페이스 크기 조정 [1]
초보
2004-12-15
1003
Valid XHTML 1.0!
All about the DATABASE... Copyleft 1999-2018 DSN, All rights reserved.
작업시간: 0.073초, 이곳 서비스는
	PostgreSQL v10.4로 자료를 관리합니다