1. Sun Microsystyems의 자바 HotSpot VM은 힙을 세 개의 영역으로 나누고 있다.
힙의 세 영역은 다음과 같다:
1) Permanent space: JVM 클래스와 메소드 개체를 위해 쓰인다.
2) Old object space: 만들어진지 좀 된 개체들을 위해 쓰인다.
3) New(young) object space: 새로 생성된 개체들을 위해 쓰인다.
New object space는 세 부분으로 다시 나누어진. 모든 새로 생성된 개체들이 가는 Eden, 그리고 그 개체들이 나이들게(Old) 되기 전에 가는 Survivor space(From, To) 1과 2가 있다.
2. Garbage Collector
프로그램은 프로그램을 진행하면서 데이터들을 저장하는 것이 필요하다. 데이터들은 모두 메모리에 저장이 되는데, 저장할 데이터가 있으면 메모리의 일정 공간을 할당받아서 사용하게 된다. 프로그램 내에서 사용하게 되는 메모리를 'heap'이라고 한다. 더 이상 사용되지 않는 데이터에게 메모리를 계속 할당해 주는 것은 메모리를 낭비하는 것이므로, 그 데이터가 사용하던 메모리를 회수하는 것이 필요하다. 이러한 사용되지 않는 메모리에 대한 회수를 'Garbage Collection'이라고 한다. 자바에서는 프로그램이 사용하는 메모리를 JVM(Java Virtual Machine)이 모두 관리한다.
3. OutOfMemory Error 및 해결방법
자바는 객체, 변수등의 생성과 동시에 메모리(Heap)를 차지하게 되고, 문제는 이 객체와 변수를 너무 많이 발생시킴으로 해서 현재 할당된 메모리(Heap)를 초과하게 된다
그래서 더이상 할당받을 메모리(Heap)가 부족하게 되면 OutOfMemory Error 발생하게 된다.
OutOfMemory Error 해결방법으로는 jdk1.4에서 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC 옵션을 사용한 GC한 상태의 Heap메모리 정보출력 한다. GC정보를 통하여 New, Old, Perm 등의 영역중 실제 어느 부분이 부족하여 OutOfMemory가 발생하는지 찾은후 부족한 영역의 충분하 size를조절해 주는 방법으로 해결할 수 있다.
4. Heap layout 할당에 영향을 주는 스위치들
5. New Generation 메모리 할당 공식
Eden = NewSize - ((NewSize/(SurvivorRatio + 2)) * 2)
From space = (NewSize - Eden)/2
To space = (NewSize - Eden)/2
6. Old Generation 메모리 할당 공식
Old = Xmx - MaxNewSize
7. JVM 스위치 설정 예제
1) 현재 http://www.affis.net 서비스는 2200개의 Jsp파일을 가지고 있고 주로 정적이 페이지들이므로 Jsp 파일 로딩에 필요한 Perm size 위주로 메모리 튜닝을 하였다.
2) 현재 http://club.affis.net 서비스는 어플리케이션 동적이페이지들로 작성되어 있고 어플리케이션 처리에 필요한 New size 위주로 메모리 튜닝을 하였다.
8. 맺음말
OutOfMemory 발생한다면 GC로그를 찍어본다. 로그를 분석해보면 New(eden, from, to), Old, Perm 등의 영역중에서 GC가 발생해도 메모리 영역이 계속 100%로 할당되는 영역이 보일것이다. 부족한 영역에 충분한 size 메모리를 할당해 주면 OutOfMemory 해결 된다.
그러나 부족한 영역에 계속해서 메모리 할당을 해주어도 사용률이 100%가 나온다면 프로그램 누수일수 있으니 프로그램을 점검해 봐야 할 것이다.
http://www.dude.co.kr
2010년 8월 31일 화요일
2010년 8월 4일 수요일
tomcat에 context 추가하기!!!
이젠 뭘 하나 하려면... 기억이 나질 않는다.... 된장.. ㅠ.ㅜ
$Tomcat\conf\Catalina\localhost 의 위치에 Default 로 설치된 admin.xml 파일을 복사하여
파일명을 원하는 컨텍스트명으로 변경한다.
예제와 같이 http://localhost:8080/client/와 같은 컨텍스트명을 원하면 client.xml로 한다.
client.xml 파일의 내용은 다음과 같다.
----[ client.xml ]----------------------------------
<Context
docBase="E:\workspace\eclipse\tomcatClient"
privileged="true"
reloadable="true">
</Context>
reloadable = true 는 클래스 변경시 자동반영 옵션이다..
--------------------------------------------------
docBase 의 위치는 소스파일(물리적인 공간) 의 위치를 입력한다.
Context 추가 후 테스트를 위해 JSP 파일을 생성한다.
테스트를 위한 index.jsp 파일의 소스는 다음과 같다.
----[ index.jsp ]-----------------------------------
<%@ page contentType="text/html; charset=euc-kr" %>
<HTML>
<HEAD>
<TITLE> New Context Client </TITLE>
</HEAD>
<BODY>
Hello New Context ~~~ client : 안녕
<%
out.println("ContextPath : " + request.getContextPath());
%>
</BODY>
</HTML>
--------------------------------------------------
위의 내용을 실행한 결과는 다음과 같다.
Context 추가 완료~!!
$Tomcat\conf\Catalina\localhost 의 위치에 Default 로 설치된 admin.xml 파일을 복사하여
파일명을 원하는 컨텍스트명으로 변경한다.
예제와 같이 http://localhost:8080/client/와 같은 컨텍스트명을 원하면 client.xml로 한다.
client.xml 파일의 내용은 다음과 같다.
----[ client.xml ]----------------------------------
<Context
docBase="E:\workspace\eclipse\tomcatClient"
privileged="true"
reloadable="true">
</Context>
reloadable = true 는 클래스 변경시 자동반영 옵션이다..
--------------------------------------------------
docBase 의 위치는 소스파일(물리적인 공간) 의 위치를 입력한다.
Context 추가 후 테스트를 위해 JSP 파일을 생성한다.
테스트를 위한 index.jsp 파일의 소스는 다음과 같다.
----[ index.jsp ]-----------------------------------
<%@ page contentType="text/html; charset=euc-kr" %>
<HTML>
<HEAD>
<TITLE> New Context Client </TITLE>
</HEAD>
<BODY>
Hello New Context ~~~ client : 안녕
<%
out.println("ContextPath : " + request.getContextPath());
%>
</BODY>
</HTML>
--------------------------------------------------
위의 내용을 실행한 결과는 다음과 같다.
Context 추가 완료~!!
http://www.dude.co.kr
Do you know tomcat monitoring tool is that Lam...
아~~따라~ 역쉬... 찾아 보면 다~~ 있어!!!!! 핫~ ㅋㅋ
일단 해당 사이트는 여기... http://www.lambdaprobe.org/d/installation.shtml
글구... 설정법... 적을려고 했는데...
이 것도 누군가가 잘~ 설명을 해두셨네... 캬~~~~~~~
------------------------------------------------------------------------------------
압축 푸신 후에 war파일을 webapps에 올려주시고
conf디렉토리 밑에 있는 tomcat-users.xml 수정해주세요.
그리고
내컴퓨터>속성>고급>환경변수>시스템 변수 에 다음을 추가해 줍니다.
아마 Lambda Probe 사이트가 현재 안 열리고 있다.
그냥 이 파일 다운 로드 해서 사용하면 됩니다.^^
사용법은
probe.war를 $tomcat_home/webapps 에 올려놓고 tomcat을 시작하면 됩니다.
http://localhost:8080/probe/index.jsp
출처: http://www.voiceportal.co.kr/418
http://www.dude.co.kr
일단 해당 사이트는 여기... http://www.lambdaprobe.org/d/installation.shtml
글구... 설정법... 적을려고 했는데...
이 것도 누군가가 잘~ 설명을 해두셨네... 캬~~~~~~~
------------------------------------------------------------------------------------
압축 푸신 후에 war파일을 webapps에 올려주시고
conf디렉토리 밑에 있는 tomcat-users.xml 수정해주세요.
<?xml version='1.0' encoding='utf-8'?>
<tomcat-users>
<role rolename="manager"/>
<role rolename="admin"/>
<role rolename="poweruser"/>
<role rolename="probeuser"/>
<role rolename="poweruserplus"/>
<user username="admin" password="admin" roles="manager,admin,poweruser,poweruserplus,probeuser"/>
<user username="tomcat" password="s3cret" roles="manager,admin"/>
</tomcat-users>
<tomcat-users>
<role rolename="manager"/>
<role rolename="admin"/>
<role rolename="poweruser"/>
<role rolename="probeuser"/>
<role rolename="poweruserplus"/>
<user username="admin" password="admin" roles="manager,admin,poweruser,poweruserplus,probeuser"/>
<user username="tomcat" password="s3cret" roles="manager,admin"/>
</tomcat-users>
그리고
내컴퓨터>속성>고급>환경변수>시스템 변수 에 다음을 추가해 줍니다.
JAVA_OPTS
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote
아마 Lambda Probe 사이트가 현재 안 열리고 있다.
그냥 이 파일 다운 로드 해서 사용하면 됩니다.^^
사용법은
probe.war를 $tomcat_home/webapps 에 올려놓고 tomcat을 시작하면 됩니다.
http://localhost:8080/probe/index.jsp
출처: http://www.voiceportal.co.kr/418
http://www.dude.co.kr
Junit 사용법
Junit Test case, suit 는 java application 을 위해 존재하는 것들이다.
위자드로 자동 생성된 소스이다.
그림을 설명하자면 먼저 브라우저에서 URL 로 TestCase 를 호출하게 되면
Java application 이 아니고 web servlet 을 테스트 하고 싶을 때 Servlet Test Case 위자드를
사용하여 파일을 생성해서 테스트 해볼수 있다.
보는 바와같이 상속받는 TestCase 클래스가 ServletTestCase 로 바뀌었다.
그리고 선택 옵션들이 많아졌다.
위자드로 자동 생성된 소스이다.
public class JunitServletTest extends ServletTestCase {
public JunitServletTest(String arg0) {
super(arg0);
}
protected void setUp() throws Exception {
super.setUp();
}
public void testMain(){
}
public void begin(WebRequest request) throws Exception {
}
public void end(WebRequest request) throws Exception {
}
}
아래소스는 상속받은 ServletTestCase 클래스의 내용이다. Servlet 테스트를 하기위해 필요한
httpServletResponse 등과 같은 http관련 클래스 변수가 아래에 보일것이다.
public class ServletTestCase extends AbstractCactusTestCase
implements CactusTestCase
{
public ServletTestCase()
{
}
public ServletTestCase(String theName)
{
super(theName);
}
public ServletTestCase(String theName, Test theTest)
{
super(theName, theTest);
}
protected ProtocolHandler createProtocolHandler()
{
return new HttpProtocolHandler(new DefaultServletConfiguration());
}
public HttpServletRequestWrapper request;
public HttpServletResponse response;
public HttpSession session;
public ServletConfigWrapper config;
}
이와 관련된 로직을 이해하기 위해서는 Cactus 작동원리를 알아야한다.
그림을 설명하자면 먼저 브라우저에서 URL 로 TestCase 를 호출하게 되면
Junit Test Runner 는 YYYTestCase 의 runTest() 메서드를 호출하게 된다.
그 메서드는 begin(), beginXXX() 차례로 수행하면서 beginXXX 에 전달된
WebRequest 매개변수를 이용해서 HTTP 관련변수를 셋팅한다.
다음은 Redirector Proxy 에 HTTP 연결을 확립하여 설정된 헤더 및 매개변수를 전달한다.
Redirector Proxy 는 이름 그대로 대리자 역할을 하는데 Client 에 생성했던것과 같은
Junit Test Runner 을 서버측에서 다시 한번 인스턴스를 생성한다. 서버측은 클라이언트와 달리
setUp, testXXX, tearDown 으로 실행된다.
testXXX 메서드는 Junit 의 assert API 를 사용하여 테스트를 수행하고 서버측 서블릿코드를
호출하게 된다. 그리고 서버객체에 대한 레퍼(Wrappers) 와 HTTP세션을 생성한다.
Exception 이 발생하게 되면 Redirector Proxy 에 의해 검출되며 클라이언트 측에 전달하여
Junit 에 의해 화면에 출력된다.
정상수행일 경우 YYYTestCase.runTest() 메소드는 endXXX, end 를 차례대로 호출한다.
서블릿 테스트 코드를 만들면 다음과 같이 간단하게 만들었다.
호출할 Servlet 서버소스 이다.
public class LoginServlet extends HttpServlet {
public void doGet(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException{
PrintWriter out = res.getWriter();
HttpSession session = req.getSession();
String id = req.getParameter("id");
String passwd = req.getParameter("passwd");
if (checkLogin(id, passwd)){
session.setAttribute("id", id);
out.print(id+"Login Failed");
}else{
out.print(id+"Login Success");
}
}
private boolean checkLogin(String id, String passwd){
return true;
}
}
다음은 TestCase 클래스이다.
import javax.servlet.ServletException;
import org.apache.cactus.ServletTestCase;
import org.apache.cactus.WebRequest;
import com.meterware.httpunit.WebResponse;
public class JunitServletTest extends ServletTestCase {
public JunitServletTest(String arg0) {
super(arg0);
}
protected void setUp() throws Exception {
super.setUp();
}
public void testMain(){
LoginServlet servlet = new LoginServlet();
try {
servlet.init(config);
servlet.doGet(request, response);
} catch (ServletException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
}
assertEquals("bcho", session.getAttribute("id"));
}
public void begin(WebRequest request) throws Exception {
}
public void beginLogin(WebRequest request) throws Exception {
request.addParameter("id", "bcho");
request.addParameter("passwd", "passwd");
}
public void endLogin(WebResponse response) throws Exception {
String responseTxt = response.getText();
assertTrue(responseTxt.indexOf("success") > 0);
}
public void end(WebResponse response) throws Exception {
}
}
http://www.dude.co.kr
2010년 7월 20일 화요일
테이블 검색 속도가 느려질때는 테이블 단편화 정...
테이블 사용량이 잦고 데이타가 많은 경우 프로시저의 이상은 없어보이는데도 데드락 현상이 발생하는 수가 있다.
테이블 검색 속도 자체가 너무 느려져서 생기는 문제인데 인덱스도 제대로 걸려 있는 상황이라면 단편화를 생각해 볼 필요가 있다.
먼저 단편화 정보를 확인하는 명령어는 DBCC SHOWCONTIG 이다.
다음은 mail_box 라는 테이블에 대한 단편화 정보를 조회해본 샘플이다.
참고로 이 테이블은 본인이 다니는 회사 제품 중에 메일 서비스에서 사용하는 테이블이다. 메일 사용량이 많은 경우 수십만건의 데이타가 존재하기도 하고 편지함 이동 및 삭제 등으로 프로그램에서의 입력, 수정, 삭제 작업이 빈번하게 일어나는 테이블이다.
DBCC SHOWCONTIG이(가) 'mail_box' 테이블을 검색하는 중...
테이블: 'mail_box'(1139691308); 인덱스 ID: 1, 데이터베이스 ID: 9
TABLE 수준 검색을 수행했습니다.
- 검색한 페이지................................: 77802
- 검색한 익스텐트 ..............................: 10259
- 익스텐트 스위치..............................: 76211
- 익스텐트당 평균 페이지 수........................: 7.6
- 검색 밀도[최적:실제].......: 12.76% [9726:76212]
- 논리 검색 조각화 상태 ..................: 99.27%
- 익스텐트 검색 조각화 상태 ...................: 86.36%
- 페이지당 사용 가능한 평균 바이트 수.....................: 3838.4
- 평균 페이지 밀도(전체).....................: 52.58%
DBCC 실행이 완료되었습니다. DBCC에서 오류 메시지를 출력하면 시스템 관리자에게 문의하십시오.
이때 속도에 영향을 미치는 부분은 익스텐트 스위치이다.
관련 용어를 설명해보자면 1페이지는 8Kbyte 를 갖는 공간이다. MSSQL DB 베이스를 구성하는 최소 단위라고 보면 된다. 1익스텐트는 8개의 페이지의 묶음이다. 고로 1 익스텐트는 8*8 = 64Kbyte 의 공간이다. 이건 뭐 -_- 의미없다. 구구단을 외자-_-)
이때 제일 중요한 수치인 익스텐트 스위치는 DBCC 문이 테이블이나 인덱스의 페이지를 이동하는 동안 익스텐트 간에 이동한 횟수를 나타낸다.
익스텐트 스위치의 값은 검색한 익스텐트의 값에 가능한 근접해야 한다. 그 말은 순서대로 정렬이 되어서 필요 이상의 이동을 하지 않았다는 의미가 된다. 반면에 단편화가 많이 되어 익스텐트 간의 이동한 횟수가 높아진다면 접근 속도에 영향을 준다.
이 비율은 검색 밀도 값으로 계산되며 값은 높을수록 좋으며 인덱스 조각화를 줄여 개선 가능하다.
위의 예에 나온 테이블은 보다시피 단편화 정도가 심각하여 시스템에 아주 많은 과부하를 가져다주게 되었다.
- 검색한 익스텐트 ..............................: 10259
- 익스텐트 스위치..............................: 76211
위에서 보다시피 익스텐트의 수보다 스위치 수가 7배 이상 많다. 그만큼 익스텐트의 순서가 꼬여 있다는 말이다.
이는 밀도에서도 바로 알 수 있다.
- 검색 밀도[최적:실제].......: 12.76% [9726:76212]
최적과 비교했을때는 거의 8배의 차이가 난다.
이런 단편화가 생기는 이유는 해당 테이블에 대한 입력, 삭제 작업이 워낙 잦은 경우 빈번하게 발생할 수 있는 문제이다.
주기적인 단편화 정리 작업을 자동으로 하도록 설정이 필요한 경우라 볼 수 있다.
참고로 단편화 정리 작업을 한 경우에는 아래의 수치로 변경이 되었다.
(그래봐야 페이지 재정렬이다 -_-)
DBCC SHOWCONTIG이(가) 'mail_box' 테이블을 검색하는 중...
테이블: 'mail_box'(1139691308); 인덱스 ID: 1, 데이터베이스 ID: 9
TABLE 수준 검색을 수행했습니다.
- 검색한 페이지................................: 50463
- 검색한 익스텐트 ..............................: 6414
- 익스텐트 스위치..............................: 6670
- 익스텐트당 평균 페이지 수........................: 7.9
- 검색 밀도[최적:실제].......: 94.56% [6308:6671]
- 논리 검색 조각화 상태 ..................: 1.90%
- 익스텐트 검색 조각화 상태 ...................: 88.29%
- 페이지당 사용 가능한 평균 바이트 수.....................: 1519.7
- 평균 페이지 밀도(전체).....................: 81.22%
DBCC 실행이 완료되었습니다. DBCC에서 오류 메시지를 출력하면 시스템 관리자에게 문의하십시오.
보다시피 익스텐트 수와 익스텐트 스위치의 수가 거의 1:1에 가깝도록 변경되었으며 당연하겠지만 밀도도 94퍼센트로 올라갔다.
물론 전체를 새로 끼워 맞추는 작업도 가능하지만 운용중인 디비에 그러한 방식의 적용은 현실적으로 어렵다는걸 잊지 말자.
자 이런 경우 단편화 정리 (조각 모음)을 하는 명령어는 다음과 같다.
dbcc indexdefrag(db이름, "소유자.테이블이름",인덱스이름)
상세 정보는 MSDN 을 참고~
테이블 검색 속도 자체가 너무 느려져서 생기는 문제인데 인덱스도 제대로 걸려 있는 상황이라면 단편화를 생각해 볼 필요가 있다.
먼저 단편화 정보를 확인하는 명령어는 DBCC SHOWCONTIG 이다.
다음은 mail_box 라는 테이블에 대한 단편화 정보를 조회해본 샘플이다.
참고로 이 테이블은 본인이 다니는 회사 제품 중에 메일 서비스에서 사용하는 테이블이다. 메일 사용량이 많은 경우 수십만건의 데이타가 존재하기도 하고 편지함 이동 및 삭제 등으로 프로그램에서의 입력, 수정, 삭제 작업이 빈번하게 일어나는 테이블이다.
DBCC SHOWCONTIG이(가) 'mail_box' 테이블을 검색하는 중...
테이블: 'mail_box'(1139691308); 인덱스 ID: 1, 데이터베이스 ID: 9
TABLE 수준 검색을 수행했습니다.
- 검색한 페이지................................: 77802
- 검색한 익스텐트 ..............................: 10259
- 익스텐트 스위치..............................: 76211
- 익스텐트당 평균 페이지 수........................: 7.6
- 검색 밀도[최적:실제].......: 12.76% [9726:76212]
- 논리 검색 조각화 상태 ..................: 99.27%
- 익스텐트 검색 조각화 상태 ...................: 86.36%
- 페이지당 사용 가능한 평균 바이트 수.....................: 3838.4
- 평균 페이지 밀도(전체).....................: 52.58%
DBCC 실행이 완료되었습니다. DBCC에서 오류 메시지를 출력하면 시스템 관리자에게 문의하십시오.
이때 속도에 영향을 미치는 부분은 익스텐트 스위치이다.
관련 용어를 설명해보자면 1페이지는 8Kbyte 를 갖는 공간이다. MSSQL DB 베이스를 구성하는 최소 단위라고 보면 된다. 1익스텐트는 8개의 페이지의 묶음이다. 고로 1 익스텐트는 8*8 = 64Kbyte 의 공간이다. 이건 뭐 -_- 의미없다. 구구단을 외자-_-)
이때 제일 중요한 수치인 익스텐트 스위치는 DBCC 문이 테이블이나 인덱스의 페이지를 이동하는 동안 익스텐트 간에 이동한 횟수를 나타낸다.
익스텐트 스위치의 값은 검색한 익스텐트의 값에 가능한 근접해야 한다. 그 말은 순서대로 정렬이 되어서 필요 이상의 이동을 하지 않았다는 의미가 된다. 반면에 단편화가 많이 되어 익스텐트 간의 이동한 횟수가 높아진다면 접근 속도에 영향을 준다.
이 비율은 검색 밀도 값으로 계산되며 값은 높을수록 좋으며 인덱스 조각화를 줄여 개선 가능하다.
위의 예에 나온 테이블은 보다시피 단편화 정도가 심각하여 시스템에 아주 많은 과부하를 가져다주게 되었다.
- 검색한 익스텐트 ..............................: 10259
- 익스텐트 스위치..............................: 76211
위에서 보다시피 익스텐트의 수보다 스위치 수가 7배 이상 많다. 그만큼 익스텐트의 순서가 꼬여 있다는 말이다.
이는 밀도에서도 바로 알 수 있다.
- 검색 밀도[최적:실제].......: 12.76% [9726:76212]
최적과 비교했을때는 거의 8배의 차이가 난다.
이런 단편화가 생기는 이유는 해당 테이블에 대한 입력, 삭제 작업이 워낙 잦은 경우 빈번하게 발생할 수 있는 문제이다.
주기적인 단편화 정리 작업을 자동으로 하도록 설정이 필요한 경우라 볼 수 있다.
참고로 단편화 정리 작업을 한 경우에는 아래의 수치로 변경이 되었다.
(그래봐야 페이지 재정렬이다 -_-)
DBCC SHOWCONTIG이(가) 'mail_box' 테이블을 검색하는 중...
테이블: 'mail_box'(1139691308); 인덱스 ID: 1, 데이터베이스 ID: 9
TABLE 수준 검색을 수행했습니다.
- 검색한 페이지................................: 50463
- 검색한 익스텐트 ..............................: 6414
- 익스텐트 스위치..............................: 6670
- 익스텐트당 평균 페이지 수........................: 7.9
- 검색 밀도[최적:실제].......: 94.56% [6308:6671]
- 논리 검색 조각화 상태 ..................: 1.90%
- 익스텐트 검색 조각화 상태 ...................: 88.29%
- 페이지당 사용 가능한 평균 바이트 수.....................: 1519.7
- 평균 페이지 밀도(전체).....................: 81.22%
DBCC 실행이 완료되었습니다. DBCC에서 오류 메시지를 출력하면 시스템 관리자에게 문의하십시오.
보다시피 익스텐트 수와 익스텐트 스위치의 수가 거의 1:1에 가깝도록 변경되었으며 당연하겠지만 밀도도 94퍼센트로 올라갔다.
물론 전체를 새로 끼워 맞추는 작업도 가능하지만 운용중인 디비에 그러한 방식의 적용은 현실적으로 어렵다는걸 잊지 말자.
자 이런 경우 단편화 정리 (조각 모음)을 하는 명령어는 다음과 같다.
dbcc indexdefrag(db이름, "소유자.테이블이름",인덱스이름)
상세 정보는 MSDN 을 참고~
피드 구독하기:
덧글 (Atom)