'2013/12 글 목록

'2013/12'에 해당되는 글 6건

sqlp 불합격....

etc 2013. 12. 31. 13:12

sqlp 시험 불합격... 실행계획을 쿼리와 주어진조건으로 작성할줄 알아야 돈이 아깝지 않을 거 같다..

스터디를 했으나 열심이 않했기때문에 이런 결과가 나온 것 같다. ㅋ

아마 sqld 시험점수와 비교해도 별반 차이가 없다..고로 공부를 않하거..^^;

'etc' 카테고리의 다른 글

소다스트림 실리더 교환 ㅡㅡ; (0)	2014.09.22

[펌]웹앱 프레임윅

language/etc 2013. 12. 18. 18:07

프론트엔드 웹앱 프레임웍 - Bootstrap, Backbone 그리고 AngularJS from Dongsu Jang

'language > etc' 카테고리의 다른 글

리눅스 top 명령어 (0)	2013.11.30
리눅스 버전 정보 확인 (아파치 버젼, 톰캣 버젼, 자바 버젼, 리눅스 버전) (0)	2013.10.30
아파치 버전확인 (0)	2013.10.30
정규 표현식(Regular Expression) (0)	2013.08.06

[펌]Okjsp 13주년 발표자료: 생존 프로그래밍 Test

language/java 2013. 12. 13. 11:49

http://www.slideshare.net/madvirus/okjsp-13-test

Okjsp 13주년 발표자료: 생존 프로그래밍 Test from beom kyun choi

'language > java' 카테고리의 다른 글

request의 Parameter 값 확인 하기 (0)	2013.11.11
[Reflection] - Value Object 로그 만들자 (0)	2013.11.08
시간을 계산해서 해당 시간보다 느리면 flase 빠르면 true를 반환한다. (0)	2013.09.16
cooke 가져오기 (0)	2013.07.23
getYear 오류 (0)	2013.07.12

[펌]파일업로드 - 비동기식전송

language/jquery 2013. 12. 13. 11:18

원글 :: http://linguist79.tistory.com/965

파일업로드를 구현시 많은 방법들이 있겠지만, 그넘의 웹표준땜에 플래시를 쓰기가 자꾸 망설여집니다.

언제까지 지원할지도 모르고...

현재 사용하는 파일전송폼은 태생적인 한계가 있습니다.

익스프로러를 시작으로 크롬 등의 브라우저가 보안상의 이유로 파일경로를 차단했습니다.

input폼에 파일을 넣고 값을 추측해봐도 경로가 안나오는 문제가 생긴거죠.

즉, fakePath 문제 입니다.(보안상의 이유로 전체경로가 전혀 보이지 않으며 값이 나타나지 않습니다)

익스프로러에서는 사용자가 옵션에 따라서 조절할 수 있지만, 근본적인 측면에서는 막혀있습니다.

자바스크립트나, Html상에서 해결할 방법은 전혀 없습니다.

이미지파일을 파일폼에 첨부하고 경로를 이용해서 본문에 첨부를 할려고 했지만 구현이 안되더군요

대안으로 플래시업로더를 사용하거나, 서버로 파일을 올린뒤 링크를 거는 방법을 택했습니다.

비동기식전송은 폼에서 파일을 선택할때 파일을 서버에 올리고 바로 값을 가져올 수 있기에 무척유용합니다.

더불어 프로그레스바를 추가해서 보다더 액티브한 폼을 만들 수 있으며, 무엇보다 표준이라는게 맘에 듭니다.

jQuery의 jquery.form.js와 json_sans_eval.js를 이용해서 파일을 전송하고 제이슨으로 리턴값을 받습니다.

첨부파일

기본폼 소스

<%@ page language="java" contentType="text/html;charset=euc-kr" session="true" %>

<html>
<head>

	<!-- 폼전송시 사용할 js -->
	<script type="text/javascript" src="jquery.js"></script>
	<script type="text/javascript" src="jquery.form.js"></script>
	
	<!-- 파싱시 사용할 js -->
	<script language="javascript" src = "json_sans_eval.js"></script>
	
	<script type="text/javascript">
		//파일전송 후 콜백 함수
		function ImguploadCallback(data,state){
	
			if (state=="error"){
				alert("이미지 전송중 예외가 발생하였습니다.\n관리자에게 문의해주세요.");
				return false;
			}

			//uploadImg.jsp에서 리턴받을 데이터가 있을경우 파싱사용
			//json_sans_eval.js 파일 script에 포함하지 않으면 예외발생
			try{
				var result = jsonParse(data);
			}catch(e){
				alert(data);
				alert("서버데이터 파싱 실패");
				return;
			}

			//서버에서 넘어온 파일명 출력  JSON문자열로 지정한 데이터를 속성처럼 사용가능합니다.
			alert("여기가 비동기 영역이지???");
			alert(result.fileName);
			alert(result.fileImgTag);
			alert(result.fileSystem);
			alert(result.fileNamePath);
			
		}
		$(function(){
			//비동기 파일 폼전송 
			var frm=$('#imgForm');
			frm.ajaxForm(ImguploadCallback);			//파일전송 후 실행할 콜백함수 지정
			frm.submit(function(){return false;});
		});

		// 파일업로드 이벤트
		function FileUploaded(){
			
			//폼전송
			var frm;
			frm = $('#imgForm');				
			frm.attr("action","uploadImg.jsp");
			frm.submit(); 

		}
	</script>
</head>
<body>
<form id="imgForm" enctype="multipart/form-data" method="post">
<input type="file" name="file1" >
<br>
<input type="button" onclick="FileUploaded()" value="폼전송">
</form>
</body>
</html>

파일업로드를 처리하는 부분 소스

<%@ page contentType="text/html;charset=euc-kr" %>
<%@ page import="com.oreilly.servlet.MultipartRequest,com.oreilly.servlet.multipart.DefaultFileRenamePolicy,java.util.*" %>
<%@ page import="java.io.*" %>
<%@ page import="org.apache.commons.lang.StringUtils" %>

<%
	MultipartRequest up = null;

	//업로드될 경로
    String path = "c:/upload";
	String original = null;
	String filename = null;
	//넘어온 파일을 저장할 파일객체 
	File f1 = null;

	String fileName = null;
	String fileImgTag = null;
	String fileSystem = null;
	String fileNamePath = null;
	
	
	
    try{

		int size = 10*1024*1024 ; // 업로드 제한 사이즈
		
		//DefaultFileRenamePolicy는 같은 파일명이 업로드될시 ex) 1.jpg일 경우 2.jpg   11.jpg 이런식으로 변경되어 저장됩니다.
		up=new MultipartRequest(request, path, size, "euc-kr", new DefaultFileRenamePolicy());

		
		
	    fileNamePath = StringUtils.defaultString(up.getParameter("file1")).toString();
		
		
		
		//file객체에 업로드된 파일을 저장
		f1 = up.getFile("file1");		
	
		fileName = f1.getName();
		fileSystem = up.getFilesystemName("file1");
		fileImgTag = "<img src=/>";


   } catch(Exception ex) {
	   out.println("<script>");
	   out.println("alert('예외메시지 = "+ex.getMessage()+"');");
	   out.println("</script>");
   }
   finally{
		System.gc();
   }

//아래 { }에 있는 부분들이 json 파싱에 이용될 문자열입니다.
%>

{
	"fileName" : "<%= fileName %>"
	"fileImgTag" : "<%= fileImgTag %>"
	"fileSystem" : "<%= fileSystem %>"
	"fileNamePath" : "<%= fileNamePath %>"
	
}

'language > jquery' 카테고리의 다른 글

[펌][jQuery] jQuery Form Plugin을 이용한 File Upload (0)	2013.12.13
jquery 기반 selectbox (0)	2013.10.29
브라우저 새로고침 단축키(F5, ctrl + r) jquery로 막기 (0)	2013.09.26
jquery popupWindow (0)	2013.09.23
[jquery] datepicker 특정날짜만 disable 시키기 (0)	2013.09.11

[펌][jQuery] jQuery Form Plugin을 이용한 File Upload

language/jquery 2013. 12. 13. 10:53

원본 :: http://jungmina.com/410

참조 :: http://blog.naver.com/kissmenot?Redirect=Log&logNo=140201550450

- jQuery Form Plugin을 이용하면 page reload 없이 file을 upload 할 수 있다.

* 소스 파일

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=euc-kr">
<title>jQuery File Upload</title>
<link href="/css/default.css" rel="stylesheet" type="text/css" />
<script type="text/javascript" src="/jquery.js"></script>
<script type="text/javascript" src="/jquery.form.js"></script>
<script type="text/javascript">
//ajax error check
$(document).ajaxError(function(event, request){
   if(request.status==500)
      alert("데이터 저장시 오류 발생!!");
   }
);

//파일전송 후 콜백 함수
function FileuploadCallback(data, state){
   if (data=="error"){
      alert("파일전송중 에러 발생!!");
      return false;
   }

   alert(data + " 파일전송 완료!!");
}

$(function(){
   //비동기 파일 전송
   var frm=$('#frmFile');

   frm.ajaxForm(FileuploadCallback);
   frm.submit(function(){return false;});
});

// 파일업로드 이벤트
function FileUpload(){
   if(!$("#Filename").val()){
      alert("파일을 선택하세요.");
      $("#Filename").focus();
      return;
   }

   //파일전송
   var frm;
   frm = $('#frmFile');
   frm.attr("action","./file_upload.jsp");
   frm.submit();
}

</script>
</head>
<body>
<div style="width:350px">
<form id="frmFile" name="frmFile" method="post" enctype="multipart/form-data">
<div>파일을 선택하세요.</div>
<div><input type="file" size="30" name="Filename" id="Filename" /></div>
<div><input type="button" class="btn menu" value="확인" onclick="FileUpload();" /></div>
</form>
</div>
</body>
</html>

* 파일 업로드 파일

<%@ page contentType="text/html;charset=euc-kr" %>
<%@ page import="com.oreilly.servlet.MultipartRequest" %>
<%@ page import="com.oreilly.servlet.multipart.DefaultFileRenamePolicy" %>
<%@ page import="java.util.*" %>
<%@ page import="java.io.*" %>
<%
   String savePath="/usr/local/apache/htdocs/vobos/tv/badboy"; // 저장할 디렉토리 (절대경로)
   int sizeLimit = 10 * 1024 * 1024 ; // 파일업로드 용량 제한.. 10Mb

   try{
      MultipartRequest multi = new MultipartRequest(request, savePath, sizeLimit,"euc-kr", new DefaultFileRenamePolicy());
      String fileName= multi.getFilesystemName("Filename");
      String originFileName = multi.getOriginalFileName("Filename");

      if(fileName == null){
          out.print("파일이 업로드 되지 않았습니다!!");
       }else{
          fileName=new String(fileName.getBytes("ISO-8859-1"),"euc-kr");
          out.print(originFileName);
       }
     }catch(Exception e){
        out.print(e.getMessage());
     }
%>

'language > jquery' 카테고리의 다른 글

[펌]파일업로드 - 비동기식전송 (0)	2013.12.13
jquery 기반 selectbox (0)	2013.10.29
브라우저 새로고침 단축키(F5, ctrl + r) jquery로 막기 (0)	2013.09.26
jquery popupWindow (0)	2013.09.23
[jquery] datepicker 특정날짜만 disable 시키기 (0)	2013.09.11

[펌] Optimizer의 원리와 Tuning (상)

language/DB 2013. 12. 11. 12:45

펌 http://webprogrammer.tistory.com/2165

Optimizer의 원리와 Tuning (상)

Oracle Optimizer의 원리 이해 및 SQL & 애플리케이션의 튜닝(상):

옵티마이저의 질의 처리 단계에 대한 이해

오라클에서 사용하는 옵티마이저(Optimizer)는 크게 RBO(Rule Base Optimizer)와 CBO(Cost Base Optimizer) 2개로 구분된다. 1992년 Oracle 7에서 처음 CBO가 지원된 이래 새로운 기능들이 적용되면서 CBO가 계속 향상되고 있는 데 반해, RBO는 오라클이 더 이상은 추구하지 않는 옵티마이저로서, 현재의 Oracle Database 10g에서도 명맥은 남아 있지만 향후는 더 이상 지원되지 않을 것이다.

옵티마이저의 입장에서 질의(query) 처리는 5단계로 나눌 수 있는데, 옵티마이저는 서브질의와 뷰의 병합(merge) 등을 수행하는‘Query Rewrite’단계와 ‘Query Optimization’단계에 참여한다. 여기서 옵티마이저는 ▲ 데이타를 어떠한 방법으로 액세스할 것이며 ▲ 올바른 결과를 어떻게 제공할 것이며 ▲ 데이타를 얼마나 효과적으로 액세스할 것인가를 결정한다. ‘QEP Generation’단계는‘Query Optimization’단계에서 제공된 정보를 이용해서 질의에 대한 최적의 실행계획(execution plan)을 만들어 내는 단계이다. CBO에서는 질의 실행계획(QEP)을 구하기 위하여 RBO보다 복잡한 단계를 거치게 된다<그림 1>, <표 1>.

소프트 파싱과 하드 파싱

SQL 문장이 옵티마이저에 의해 처리되고 그 결과물로서, SQL 문장이 어떻게 실행될 것인지의 정보, 즉, QEP가 생기게 된다. 이들 정보는 한번 쓰고 버리는 것이 아니라 오라클의 캐쉬(cache) 영역인 SGA의 공유 풀 (shared pool)에 이들 모든 정보를 캐쉬화해 관리한다. 다음 번에 같은 SQL 문장이 사용자에 의해서 실행되면, 이를 재활용하게 된다.

SQL 문장이 실행되면, 우선 SQL 문장 텍스트의 스트링을 해쉬 함수를 통과시켜 결과 값에 해당되는 버킷(어레이형 구조)에 매달린 체인 정보에서 같은 SQL 문장이 존재하는지 찾는 처리절차를 수행하게 된다. 또한 같은 SQL 문장을 찾았어도 여러 버전이 존재할 수 있다. 여러 버전이란, 같은 SQL 문장(대/소문자, 화이트 스페이스 등이 모두 같아야 함)이지만 서로 다른 스키마의 테이블(예, scott의 emp, sys의 emp)이거나, 바인드 변수 를 사용한 경우는 바인드 변수의 타입, 길이 등에 의해서도 서로 다른 버전이 된다는 것이다. 이와 같이 같은 SQL 문장에 같은 버전을 찾았다면 이를 ‘소프트 파싱(soft parsing)’이라고 한다.

그렇지만, 체인을 다 찾았는데 같은 문장을 발견하지 못했다면, 해당 SQL 문장이 Parsing/Optimizing 단계를 거친 결과로 나온 정보를 저장하기 위해 공유 풀로부터 메모리를 확보받고, 기록한 정보를 체인에 매달게 된다. 이를 ‘하드 파싱(hard parsing)’이라고 한다. 당연히 하드 파싱의 작업량이 소프트 파싱의 작업량에 비해 월등히 클 것이다<그림 2>.

이와 같은 소프트 파싱과 하드 파싱의 과정을 생각해 볼 때, 집중적인 SQL 문장이 실행되는 OLTP(초당 수천 ~ 수만 개 이상)에서 하드 파싱이 많다면 어떻게 될까? 한정된 메모리인 캐쉬에 새로운 메모리를 계속 할당하고, LRU 알고리즘에 의해 제거하고, 체인에 매달고 끊는 등의 일들을 반복해야 할 것이다. 또한 하드 파싱은 복잡한 처리과정을 거치므로 많은 자원(CPU)을 사용하게 된다. 그러므로 OLTP 환경에서는 이와 같은 하드 파싱을 가능한 줄이도록 해야 한다. 특히 SQL 실행 규모가 큰 OLTP 업무는 1% 미만을 권장한다.

애플리케이션을 개발할 때 이러한 하드 파싱을 줄이기 위한 방법으로 거의 대부분의 데이타베이스 접속 방식(JDBC, ODBC, ADO, PRO*C 등) 에서 자주 사용되는 SQL 문장들은 바인드 변수 기법들을 사용하여 개발하는 방법들을 제공하고 있다. 또한 일부에서는 소프트 파싱 자체도 줄일 수 있는 기법들을 제공하고 있다. 실제 이러한 기법을 적용해서 튜닝한 결과, 시스템 CPU/메모리 측면에서 40~50% 이상 개선된 사례가 많이 있다. 혹시 현재 운영중인 시스템이 사용자가 많아지면서 CPU 리소스가 급격히 증가해, 라이브러리 캐쉬, 공유 풀 경합 현상이 발생한다면, 이러한 점을 의심해 볼 수 있다.

<표 4>는 SQL 문장을 바인드 변수를 사용한 공유 SQL과, 상수를 결합한 형태로 SQL 문장을 만들어 실행시키는 비공유 SQL을 9,999회 실행시켜 오라클의 공유 풀 메모리 사용현황과 파싱시 CPU 사용시간을 테스트 한 것이다(단, 그 결과치는 실행 서버별로 차이가 있다).

결론적으로 보면, 비공유 SQL 방식의 사용 메모리와 CPU 사용률이 실행 규모에 비례해 증가하고, 실행된 SQL 문장이 기존에 캐쉬화되어 있는 SQL 문장들을 밀어내는 역할을 한다는 것을 알 수 있다.

이와 같은 SQL 문장을 공유하기 위해서 오라클 입장에서 처리해주는 CURSOR_SHARING이라는 파라미터를 제공하기도 한다. 그러나, CURSOR_SHARING은 모든 상수를 다 바인드 변수로 바꿔버리기 때문에 개발자가 의도하지 않은 Literal까지도 바꾸게 되므로, 애플리케이션을 수정할 수 있다면 가능한 애플리케이션 단에서 바인드 변수를 사용하는 것이 효과적이다.

하드 파싱을 줄이기 위해 모든 업무에 바인드 변수 사용방법을 적용하는 것은 잘못된 생각이다. 옵티마이저의 입장에서 보면, 바인드 변수 기법 보다는 Literal을 사용한 비공유 SQL 방식을 좋아한다. Literal SQL 문장일 경우는 상수 값에 따라서 범위를 정확히 알 수 있기 때문에 효과적인 플랜을 결정하는 주요 결정요소로 작용하기 때문이다. 즉 바인드 변수 기법은 옵티마이저의 판단에는 좋지 않지만 SQL 문장이 집중적으로 실행되는 OLTP 환경에서 하드 파싱의 비율을 줄이기 위한 방법인 것이다. 즉, 업무의 특징에 따라서 다른 적용방식이 사용되어야 한다. 다음은 OLTP와 DW의 특징에 따라 다르게 고려되어야 할 사항이다.

• OLTP의특징
- 목표 : 신속한 응답시간, 적은 데이타 처리량
- 파싱 타임을 최소화하고 SQL 등이 공유될 수 있도록 바인드 변수를 사용해야한다.
- 인덱스의 사용률이 높아야 한다.
- 정렬(sorting)을 최소화해야 한다.
- Nested Loop Join(FIRST_ROWS_n) 방식으로 많이 유도한다.

• DW의특징
- 목표 : 최고의 처리량, 방대한 데이타 처리량
- 인덱스의 참조는 중요한 사항이 아니다.
- 정렬 또는 Aggregate함수 등이 중요한 역할을 한다.
- Hash Join 등을 많이 사용하도록 유도한다.
- 파싱 타임 등은 그리 중요하지 않으며, 바인드 변수의 사용이 문제가 될 수 있다.

- 병렬 질의 등의 사용률을 높인다.

Rule Base Optimizer

질의 최적화(query optimization)에서 RBO(Rule Base Optimizer)는 정해진 랭킹(ranking)에 의해 플랜을 결정한다. 같은 랭킹이라면 Where 절의 뒤부터, From절 뒤의 객체가 우선 순위를 갖는다. 한 객체(예 : 테이 블)에서 같은 랭킹의 인덱스가 있다면 가장 최근에 만들어진 인덱스를 사 용한다. 이는 CBO(Cost Base Optimizer)에서도 같이 적용되는 사항이다.

다분히 RBO는 개발자들이 프로그래밍 단계에서 SQL 문장 구조의 인위적인 조정 등으로 인덱스를 사용 못하게 하는 등 개발자가 코딩에 신경을 많이 써야 하는 문제점이 있다. 또한 RBO는 해당 질의에 대한 테이블의 인덱스가 존재한다면 전체 90% 이상의 대상이어도 인덱스를 선택한다는 것이다. 즉, RBO는 무조건 다음과 같은 미리 정해진 룰을 기준으로 플랜을 결정하게 된다. 1992년 Oracle 7에서 CBO가 지원되면서 CBO는 계속적인 신기능의 적용으로 발전해 온 반면, RBO는 더 이상의 기능 향상은 없으며, 향후는 CBO만 지원될 계획이다. 그러므로 RBO에 더 이상의 미련을 갖지 말기 바라며, CBO의 훌륭한 기능들을 적극 활용하길 바란다.

다음은 RBO의 랭킹을 정리한 것이다.

Path 1 : Single Row by Rowid
Path 2 : Single Row by Cluster Join
Path 3 : Single Row by Hash Cluster Key with Unique or Primary Key
Path 4 : Single Row by Unique or Primary Key
Path 5 : Clustered Join
Path 6 : Hash Cluster Key
Path 7 : Indexed Cluster Key
Path 8 : Composite Index
Path 9 : Single-Column Indexes
Path 10 : Bounded Range Search on Indexed Columns
Path 11 : Unbounded Range Search on Indexed Columns
Path 12 : Sort-Merge Join
Path 13 : MAX or MIN of Indexed Column
Path 14 : ORDER BY on Indexed Column
Path 15 : Full Table Scan

특히 Path 8, 9, 10에 주의를 해야 한다. 예를 들면, ‘emp’ 테이블에 ‘A’ 인덱스가 “deptno”로 구성되어 있고, ‘B’ 인덱스가 “deptno + empno”로 구성되어 있다면, 다음과 같은 SQL 문장은 ‘A’ 인덱스를 사용 하게 된다. 조건이 Bounded Range Search(Between)로 왔기 때문에 아래의 SQL 문장에서 (A)와 (B)의 랭킹은 (A) ==> Rank 9 , (B) ==> Rank 10 조건이 되므로 싱글 칼럼 인덱스를 사용한다는 것이다.

그러면, 이제CBO에 대해 살펴보기 전에, 참고로 RBO를 CBO로 전환한 사례를 잠깐 소개하겠다.

현재 RBO를 사용하고 있는 상황에서 마이그래이션시 CBO로 전환하고 싶으나, 막연히 두려운 부분도 많을 것이다. 실제 RBO에서 CBO로 전환하고 나서 가장 효과를 보는 부분은 배치잡 형태이다. 특히 Oracle9i Database 이상의 WORKAREA_SIZE_POLICY=AUTO로 운영하는 곳 이라면 더욱 더 그럴 것이다. 그러나 OLTP의 변화는 조심해야 한다. 아래의 경우는, 이전하면서 옵티마이저 모드를 RBO에서 CBO로 전환한 것 뿐만 아니라, 블록 사이즈와 CBO 옵티마이저에 민감한 db_file_multi block_read_count 값도 크게 늘렸다. 특히 WORKAREA_SIZE_ POLICY=AUTO로 필요한 워킹 메모리(Sort, Hash, Bitmap 등)를 옵티마이저가 판단하에 가능한 충분히 사용하게 하는 방식을 사용하였다.

그러다 보니, CBO에 영향을 주는 소트 메모리와 해쉬 메모리가 풍부하게 되었고, 블록 사이즈도 커졌으며, 풀 테이블 스캔의 정도를 결정하는 db_file_multiblock_read_count 값도 아주 커진 상태이다. 또한 마이그래이션되면서 데이타가 재정리되어 있는 상태이므로, 풀 테이블 스캔과 Sort Merge Join, Hash Join의 경향이 커진 상태이다. 그러므로 배치잡의 경우는 최적의 조건이 되었으나, 기존에 주로 Nested Loop Join을 선호하 던 RBO 환경의 OLTP들은 많은 플랜의 변화에 직면하게 된다. 그러면 이러한 부분을 어떻게 보정해 줄 것인가?

optimizer_index_caching, optimizer_index_cost_adj의 파라미터가 그 해답일 것이다. 가능한 Nested Loop Join를 선호하고, CBO의 옵티마이저 모드가 인덱스에 점수를 더 주어서 인덱스의 비중을 키울 수가 있는 것이다. 물론 이러한 전환형태 말고 옵티마이저 모드를 FIRST_ROWS_n으로 운영하거나, 아웃라인을 이용하는 방법 등도 있을 것이다. 여러 방법이 있겠지만, 필자는 아래와 같은 방법을 선호한다.

다음은 마이그래이션시 RBO에서 CBO로 전환한 사례이다.

Cost Base Optimizer

질의 최적화에서 CBO(Cost Base Optimizer)는 해당 SQL 문장이 참조하고 있는 객체들(테이블, 인덱스 등)에 대한 수집된 통계정보(statistics)의 값과 데이타베이스 파라미터(init.ora) 설정 값을 기초로 가장 적은 비용 (cost)이 발생되는 플랜을 결정하는 옵티마이저 방식이다.

여기서 중요한 사실은 RBO에서는 전혀 사용되지 않았던 통계정보를 CBO에서는 이용한다는 것이다. 이들 통계정보는 DBA에 의해서 또는 자동 수집 기능(Oracle9i Database Release 2, Oracle Database10g)에 의해 객체들의 통계정보를 관리하는 시스템 딕셔널리(Dictionary)에 저장되고, 이 정보를 CBO 옵티마이저가 이용하는 것이다. 이들 정보는 SQL 문장을 실행하는 데 얼마만큼의 I/O 횟수가 발생할 것인가를 계산하기 위한 각종 데이타를 가지고 있다. 여기서 중요한 사실은 I/O 크기는 중요하지 않으며 I/O 횟수가 중요하다는 것이다. 즉, CBO 옵티마이저는 SQL 문장에 대한 여러 가지 경우의 수별로 I/O의 횟수에 비례한 비용을 산출해내고, 이들 비용에서 가장 작은 비용을 갖는 플랜을 결정한다는 것이다. 즉, 비용 은 I/O 횟수에 비례하는 값이라고 보면 쉬울 것이다.

그러나, Oracle Database 10g부터는 비용의 단위 기준이 I/O에서 처리시간으로 바뀌었다(time base). 또한 Oracle9i Database부터 시스템 통계정보(CPU, 디스크 액세스 타임)를 이용해서 I/O로 환산한 방식을 제공하였으나, 이것은 단지 옵션이었다. 그러나, Oracle Database 10g부터는 시스템 통계정보(CPU, 디스크 액세스 타임)를 이용해서 처리시간으로 환산한 방식을 디폴트로 사용하므로 상당히 정확한 플랜을 만들어내며, 실행 예측 시간도 상당히 정확하다.

그러면, 여기서 잠깐 CBO에서 사용되는 통계정보가 저장된 Dictinary 정보 예를 참고로 살펴보자.

[USER|ALL|DBA]_TABLES : Table의 통계정보
NUM_ROWS,BLOCKS,AVG_ROW_LEN,SAMPLE_SIZE,LAST_ANALYZED

[USER|ALL|DBA]_INDEXES : Index의 통계정보
BLEVEL,LEAF_BLOCKS,DISTINCT_KEYS,AVG_LEAF_BLOCKS_PER_KEY,
AVG_DATA_BLOCKS_PER_KEY,CLUSTERING_FACTOR,NUM_ROWS,SAMPLE_SIZE,
LAST_ANALYZED

[USER|ALL|DBA]_TAB_COLUMNS : Column의 통계정보
NUM_DISTINCT,LOW_VALUE,HIGH_VALUE,DENSITY,NUM_NULLS,NUM_BUCKETS,
LAST_ANALYZED,SAMPLE_SIZE,AVG_COL_LEN

[USER|ALL|DBA]_TAB_HISTOGRAMS : Column의Data 분포도 정보
TABLE_NAME,COLUMN_NAME,ENDPOINT_NUMBER,ENDPOINT_VALUE,
ENDPOINT_ACTUAL_VALUE

기타 파티션 / 클러스터 등에 대한 통계정보

그러면“select * from dept where deptno = 10”과 같은 SQL 문장을 실행해야 한다고 가정하자. 여기서 dept Table은 deptno에 대한 인덱스가 있고, 테이블은 전체 10 블록으로 구성되어 있으며, 풀 테이블 스캔일 경우 I/O 단위를 결정하는 파라미터는 DBA가 db_file_multiblock_read_count=8로 지정하여 운영하고 있다고 가정하자 . 여기서 RBO라면 무조건 인덱스를 타는 플랜을 결정하였을 것이다.

그러나, CBO의 경우는 deptno의 인덱스를 이용해 실행하면, 3회(인덱스는 싱글 블록 단위 I/O)의 I/O가 발생한다고 가정하고, 풀 테이블 스캔의 경우는 2회(8블록 + 2블록)의 I/O가 발생한다고 가정하면, CBO에서는 인덱스가 있음에도 I/O 횟수 측면에서 더 효과적인 풀 테이블 스캔을 선택한다는 것이다. 그러므로 CBO는 이와 같이 가능한 정확한(현실 데이타와 맞는) 통계정보와 적절한 데이타베이스의 파라미터인 init.ora에 의해 플랜이 결정되는 것이다.

CBO에서만 가능한 기능들

CBO는 오라클의 신기능을 지원하도록 지속적으로 발전하고 있으며, 다음의 경우는 반드시 CBO에서만 플랜 결정시 검토되거나 무조건 CBO로 동작되는 경우이다. 예를 들어, 파티션 테이블을 사용한다면 통계정보가 없더라도 무조건 CBO로 동작된다는 것이다.

• Partitioned tables (*)
• Index-organized tables
• Reverse key indexes
• Function-based indexes
• SAMPLE clauses in a SELECT statement (*)
• Parallel execution and parallel DML
• Star transformations
• Star joins
• Extensible optimizer
• Query rewrite (materialized views)
• Progress meter
• Hash joins
• Bitmap indexes
• Partition views (release 7.3)
• Hint (*)
• Parallel DEGREE & INSTANCES - ‘DEFAULT’도 해당 (*)

CBO의 옵티마이저에 영향을 줄 수 있는 파라미터

옵티마이저가 플랜을 수립하는 데 영향을 줄 수 있는 파라미터 값이 무엇인지를 알고 있는 것이 무엇보다 중요하다. 실제 옵티마이저가 참조하는 파라미터는 Oracle9i Database 기준으로 보더라도 60여 개에 이른다. 특히 DBA는 이들 옵티마이저의 파라미터 설정에 신중해야 한다. 또한 이들 파라미터의 효과적인 설정은 개발 중이거나, 마이그래이션 중에 업무의 특징을 판단한 다음, 해당 업무에 가장 효과적인 것을 설정해야 한다. 기준이 잘못되면 개발자들은 SQL 문장마다 힌트를 넣기 바쁠 것이고, 많은 인적 자원을 튜닝에 소모해야 할 것이다. 그러므로 대부분의 업무들이 최적화되어 잘 운영될 수 있는 형태로 이들 파라미터를 바꿔가면서 기준을 정하는 것이 중요하다. 물론 이들 값보다도 CBO에서 사용되는 통계정보가 중요하다는 것은 당연한 사실이다. 오라클에서는 개발장비에도 운영장비에 있는 통계정보와 같게 운영할 수 있도록 DBMS_STATS 패키지를 제공한다.

다음은 질의 수행시 옵티마이저가 플랜을 수립하기 위해 참조한 파라미터 중 일부이다(버전마다 다르다).

OPTIMIZER_PERCENT_PARALLEL (Default = 0)
Optimizer_Percent_Parallel의 Parameter는 CBO가 비용을 계산하는 데 영향을 주는 파라미터이다. 즉 수치가 높을수록 병렬성을 이용하여 풀 테이블 스캔으로 테이블을 액세스하려고 한다. 이 값이 0인 경우는 최적의 시리얼 플랜이나 패러렐 플랜을 사용하며, 1~100일 경우는 비용 계산에서 객체의 등급을 사용한다.

OPTIMIZER_MODE (Default=Choose(Oracle7 ~ Oracle9i
Database),ALL_ROWS)
{Choose(<=9i)|Rule(<=9i)|First_rows|First_rows_n(> =Oracle9i)|All_rows}
기본적인 옵티마이저 모드를 결정한다 (왼쪽상자 기사 ‘옵티마이저 모드의 종류 및 특징’ 참조).

HASH_AREA_SIZE, HASH_JOIN_ENABLED (Oracle Database 10g : _ hash_join_enabled=true)
위의 파라미터 값에 따라서 Hash Join으로 유도할 수 있다. Hash Join이 가능하고 해쉬 메모리가 충분하다면, 플랜에 Hash Join의 경향이 커진다.

OPTIMIZER_SEARCH_LIMIT (Default = 5)
옵티마이저에게 조인 비용을 계산할 경우, From절에 나오는 테이블의 개수에 따라서 조인의 경우의 수가 있을 수 있으며, 옵티마이저는 이들 각각의 경우의 수에 대한 조인 비용을 계산하게 된다. 물론 일부 예외사항은 있다. 예를 들어, Cartesian Production Join 등은 우선 순위가 낮으므로 뒤로 미뤄질 것이다. 이 파라미터의 값이 5일 경우 From절에 5개의 테이블에 대해서 모든 조인의 경우의 수를 가지고 비용을 계산하게 되며, 그 개수는 5!=120개의 경우의 수 에 대한 조인 비용을 계산하게 되므로 옵티마이저가 많은 시간을 소모하게 되므로 성능에 영향을 미칠 수도 있다.

SORT_AREA_SIZE , SORT_MULTIBLOCK_READ_COUNT
위의 파라미터의 값에 따라서 Sort Merge Join으로 유도할 수 있다. 소트 메모리가 충분하다면, 플랜에 Sort Merge Join의 경향이 커진다.

DB_FILE_MULTIBLOCK_READ_COUNT
이 파라미터의 수치가 클수록 인덱스 스캔보다는 풀 테이블 스캔의 비중이 높아진다. 이 파라미터는 옵티마이저의 플랜 결정에 민감하게 영향을 주는 값이다. 즉, 이 값이 커지면 풀 테이블 스캔과 병행해서 Sort Merge Join 또는 Hash Join의 경향이 커진다.

OPTIMIZER_INDEX_CACHING (Default = 0)
CBO가 Nested Loop Join을 선호하도록 조절하는 파라미터, Nested Loop Join시 버퍼 캐쉬 내에 이너 테이블의 인덱스를 캐쉬화하는 비율(%)을 지정하므로 Nested Loop Join시 성능이 향상되며, 옵티마이저는 비용 계산시 이 비율을 반영하여 Nested Loop Join을 선호하도록 플랜이 선택된다(0~100). 100에 근접할수록 인덱스 액세스 경로가 결정될 가능성이 높다. 기존의 RBO를 CBO로 전환시 옵티마이저를 RBO 성향으로 보정하는 데 효과적이다.

OPTIMIZER_INDEX_COST_ADJ (Default = 100)
옵티마이저가 인덱스를 사용하는 위주의 플랜으로 풀릴 것인지 또는 가능한 사용하지 않을 쪽으로 풀릴 것인지의 비중을 지정한다. CBO는 RBO처럼 인덱스를 사용하도록 플랜이 주로 만들어지게 되나, 인덱스가 있다고 해서 RBO처럼 인덱스를 이용한 플랜으로 처리되는 것은 아니다. 인덱스를 이용하는 플랜 위주로 하고자 한다면 100(%) 이하를, 가능한 인덱스를 사용하지 않고자 한다면 100 이상을 지정한다(1 ~ 10000). 이 파라미터는 기존의 RBO를 CBO로 전 환시 옵티마이저를 RBO의 인덱스 위주 성향으로 보정하는데 효과적이다.

WORKAREA_SIZE_POLICY (AUTO | MANUAL)

옵티마이저가 [HASH|SORT|BITMAP_MERGE|CREATE_ BITMAP] *_AREA_SIZE를 자동으로 결정하는 PGA 자동 관리 방식으로, 인스턴스에 속한 모든PGA의 메모리의 합이PGA_AGGREGATE_TARGET에서 설정된 메모리를 가능한 넘지 않는 범위 내에서 Workarea(Sort, Hash, Bitmap 등)를 충분히 사용하고자 하는 방식이다. 플랜은 할당된 Workarea를 가지고 플랜을 결정하게 되므로 풍부한 메모리에 의해 Hash Join, Sort Merge Join등을 선호하는 경향이 높다. 내부적으로 히든 파라미터로 *_AREA_SIZE의 값을 가지고 플랜을 결정할 수도 있으나 인위적인 설정 없이는 자동 할당된 메모리로 플랜이 결정된다.

OPTIMIZER_DYNAMIC_SAMPLING (Default = 1(Oracle9i Database), 2(Oracle Database 10g))

더 나은 플랜을 결정하기 위한 목적으로 더 정확한 Selectivity & Cardinality 를 구하기 위한 방법으로 0 ~ 10 레벨이 있으며, 레벨이 높을수록 SQL 문장의 실행 시점에 통계정보를 만들기 위해 테이블의 데이타를 샘플링하기 위한 추가적인 Recursive SQL이 발생된다.

DYNAMIC_SAMPLING(0 ~ 10) 힌트를 통해서도 같은 기능을 할 수 있다. 그러나 내부적으로 추가적인 테이블 액세스 의 비용이 발생하므로OLTP에서는 주로 사용하지 않는다. 특히OLTP 환경에 서 레벨을 디폴트 값 이상 높여 놓지 않도록 한다. Oracle Database 10g의 경우 통계정보가 없다면 ‘다이나믹 샘플링’이 적용된다.

다음은 Oracle Database 10g의 플랜 및 다이나믹 샘플링의 예이다.

옵티마이저 모드의 종류 및 특징

• 인스턴스 레벨 : optimizer_mode = {Choose|Rule|First_rows| First_rows_n| All_rows}

• 세션 레벨 : 인스턴스 레벨에 우선
ALTER SESSION SET optimizer_mode =
{Choose|Rule|First_rows|First_rows_n|All_rows}

• 스테이트먼트 레벨 : 힌트를 사용하며, 인스턴스, 세션 레벨에 우선

• Oracle9i Database에서 FIRST_ROWS_n 옵티마이저 모드가 추가되었음(N : 1, 10, 100, 1000).

• Oracle Database 10g에서는 CHOOSE, RULE 모드는 더 이상 지원되지 않으나, 기능은 남아있다.

• OPTIMIZER_MODE=CHOOSE 일경우
통계정보가 없다면 기본적으로 RBO로 플랜이 결정된다. 그러나, ‘RULE’, ‘DRIVING_SITE’ 힌트 이외의 힌트가 왔다면 CBO로 결정된다(힌트는 룰의 규정을 깨므로 CBO로 동작됨).

• Parallel Degree, Partition Table, SAMPLE절 등이 있으면 무조건 CBO

• OPTIMIZER_MODE=First_rows|First_rows_n|All_rows일 경우 통계 정보의 존재 여부와 관계 없이 무조건 CBO로 처리하려고 함.

통계정보가 없다면 Heuristics Value를 이용하거나, Oracle9i Database 이상일 경우는 다이나믹 샘플링의 레벨에 따라 테이블의 데이타를 샘플링해서 CBO로 플랜이 결정된다. 그러나, 플랜이 비효율적일 수 있다.

• 통계정보가 있으나 옵티마이저 모드가 RULE일 경우, 다른 힌트가 오지 않은 경우와 Parallel Degree, Partition Table, SAMPLE절 등이 나오지 않은 경우는 RBO로 처리된다.

CBO를 위한 통계정보 운영 방법

통계정보는 CBO의 플랜 결정에 사용되는 객체들의 물리적인 구성정보를 나타낸다. 즉, 테이블이 몇 블록으로 구성되어 있으며, 몇 건의 로우들을 가지고 있으며, 평균 로우 길이는 어느 정도이며, 칼럼의 Min/Max 값의 분포, Distinct 값, 인덱스의 레벨, 키(key)당 Leaf Block 수 등의 정보들을 나타낸다. 이들 정보는 CBO의 플랜 결정의 기초 자료로 사용된다. 이들 통계정보를 생성하기 위해서는 ANALYZE 명령어를 이용하거나 DBMS_STATS 패키지를 이용하면 된다. 그러나 2개의 차이점에 주의해야 하며, DBMS_STATS를 지원하는 Oracle8i Database 이상부터는 DBMS_STATS를 사용하기를 권장하고 있다.

Analyze 명령어와 DBMS_STATS의 차이점

• Analyze는 Serial Statistics Gathering 기능만 있는 반면, DBMS_STATS은 Parallel Gathering 기능이 있다.

• Analyze는 파티션의 통계정보를 각 파티션 테이블과 인덱스에 대해서 수집하고, Global Statistics는 파티션 정보를 가지고 계산하므로, 비정확할 수 있다. 그러므로 파티션 또는 서브파티션이 있는 객체에는 DBMS_STATS를 사용하여야 한다.

• DBMS_STATS은 전체 클러스터에 대해서는 통계정보를 수집하지 않는다. 그러므로 Analyze를 사용한다.

• DBMS_STATS은 CBO와 관련된 통계정보만을 수집한다. 즉, 테이블의 EMPTY_BLOCKS, AVG_SPACE,CHAIN_CNT 등은 수집되지 않는다.

• DBMS_STATS은 사용자가 지정한 통계정보 테이블에 수집된 통계정보를 저장할 수 있고, 딕셔너리로 각 칼럼, 테이블, 인덱스, 스키마 등을 반영할 수 있다.

• DBMS_STATS 은 IMPORT/EXPORT 기능 및 추가적인 기능이 많다. 이 기능을 이용하여 운영 DB의 통계정보를 개발장비의 통계정보로 복사할 수 있으므로 개발장비의 플랜을 운영장비와 같게 만들 수 있다(매뉴얼 참조).

다음은 Analyze 명령어에만 있는 기능이다.

• Structural Integrity Check 기능
analyze { index/table/cluster } (schema.){ index/table/cluster } validate structure (cascade) (into schema.table);

• Chained Rows 수집 기능
ANALYZE TABLE order_hist LIST CHAINED ROWS INTO ;

시스템 통계정보 (>= Oracle9i Database)

시스템 통계정보는 객체의 통계정보와 같이 사용되는 정보로서, 기존의 Oracle8i Database까지의 I/O 중심의 플랜 방식에 CPU와 디스크 I/O 속도와 같은 시스템 자원의 효율을 반영하여 보다 효율적인 플랜을 결정하기 위한 방법으로, Oracle9i Database에서 처음 소개되었으며, 옵션 기능으로 DBA에 의해 사용될 수도 있고 사용하지 않을 수도 있었다. Oracle Database 10g에서는 시스템 통계정보가 기본적으로 수집되고 사용된다. 그러므로 기존의 I/O 횟수만 가지고 플랜을 결정하던 부분이 Oracle Database 10g에서는 시스템의 자원의 성능도 고려되어 보다 정확한 플랜을 결정할 수 있게 되었다.

이들 시스템 통계정보는 DBMS_STATS 패키지를 이용해서 수집된다.

Oracle Database 10g에서는 기본적으로 수집되는 값들이 있으며, 또한 사용자가 수집해야 하는 항목도 있다. 다음은 Oracle Database 10g의 시스템 통계정보의 수집형태를 보여주고 있다.

더 자세한 내용 : 오라클 매뉴얼 [Database Performance Tuning Guide and Reference]

'language > DB' 카테고리의 다른 글

SQLDeveloper 4 버전 세션 유지 (0)	2014.11.13
테이블 데이터의 마지막 수정일자를 구해오는 방법 (0)	2013.11.26
MSSQL 에서 SP 내용 알아내는 법 (0)	2013.11.01
sql 정규식 (0)	2013.09.26
여러행을 한줄로 (0)	2013.09.26

◀ PREV : [1] : NEXT ▶

Coding Like a Movie

'2013/12'에 해당되는 글 6건

sqlp 불합격....

'etc' 카테고리의 다른 글

[펌]웹앱 프레임윅

'language > etc' 카테고리의 다른 글

[펌]Okjsp 13주년 발표자료: 생존 프로그래밍 Test

'language > java' 카테고리의 다른 글

[펌]파일업로드 - 비동기식전송

'language > jquery' 카테고리의 다른 글

[펌][jQuery] jQuery Form Plugin을 이용한 File Upload

'language > jquery' 카테고리의 다른 글

[펌] Optimizer의 원리와 Tuning (상)

'language > DB' 카테고리의 다른 글

티스토리툴바