반응형

반응형

from : http://nettop.pe.kr
from : http://kkaok.pe.kr
from : http://koug.net


<25가지 SQL작성법>

1.데이터와 비즈니스 어플리케이션을 잘 알아야 한다.

동일한 정보는 다른 비즈니스 데이터 원천으로부터 검색될 수 있다. 이러한 원천
에 익숙해야 한다. 당신은 당신의 데이터베이스 안의 데이터의 크기와 분포를 반
드시 알아야 한다. 또한 SQL을 작성하기 전에 비즈니스 개체 안의 관계와 같은
데이터 모델을 전체적으로 이해해야 한다. 이러한 이해는 당신이 여러 테이블에
서 정보를 검색하는데 있어서 보다 좋은 쿼리를 작성할 수 있다. DESIGNER/2000
과 같은 CASE TOOLS은 다른 비즈니스와 데이터베이스 객체사이의 관계를 문서화
하는데 좋은 역할을 한다.

2.실제 데이터를 가지고 당신의 쿼리를 검사하라.

대부분의 조직은 개발, 검사, 제품의 3가지 데이터베이스 환경을 가진다. 프로그
래머는 어플리케이션을 만들고 검사하는데 개발 데이터베이스 환경을 사용하는
데, 이 어플리케이션이 제품 환경으로 전환되기 전에 프로그래머와 사용자에 의
해 검사 환경하에서 보다 엄격하게 검토되어야 한다.
SQL이 검사 환경하에서 테스트될 때, 검사 데이터베이스가 가지고 있는 데이터
는 제품 데이터베이스를 반영해야 한다. 비실제적인 데이터를 가지고 테스트된
SQL문은 제품 안에서는 다르게 작동할 수 있다. 엄격한 테스트를 보장하기 위해
서는, 검사 환경하에서의 데이터 분포는 반드시 제품 환경에서의 분포와 밀접하
게 닮아야 한다.

3.동일한 SQL을 사용하라.

가능한한 BIND VARIABLE, STORED PROCEDURE, PACKAGE의 이점을 활용하라. IDENTICAL
SQL문의 이점은 PARSING이 불필요하기에 데이터베이스 서버안에서 메모리 사용
의 축소와 빠른 수행을 포함한다. 예로서 아래의 SQL 문은 IDENTICAL하지 않다.

SELECT * FROM EMPLOYEE WHERE EMPID = 10;
SELECT * FROM EMPLOYEE WHERE EMPID = 10;
SELECT * FROM EMPLOYEE WHERE EMPID = 20;

그러나 I_EMPID라고 이름 주어진 BIND VARIABLE을 사용하면 SQL 문은 이렇게 된
다.
SELECT * FROM EMPLOYEE WHERE EMPID = :I_EMPID;

4.주의 깊게 인덱스를 사용하라.

테이블상에 모든 필요한 인덱스는 생성되어야 한다. 하지만 너무 많은 인덱스는
성능을 떨어뜨릴 수 있다. 그러면 어떻게 인덱스를 만들 칼럼을 선택해야 하는
가?

*최종 사용자에 의해 사용되는 어플리케이션 SQL과 쿼리의 WHERE 절에서 빈번
하게 사용되는 칼럼에 인덱스를 만들어야 한다.

*SQL 문에서 자주 테이블을 JOIN하는데 사용되는 칼럼은 인덱스되어야 한다.

*같은 값을 가지는 ROW가 적은 비율을 가지는 칼럼에 인덱스를 사용하라.

*쿼리의 WHERE 절에서 오직 함수와 OPERATOR로 사용되는 칼럼에는 인덱스를 만들
면 안된다.

*자주 변경되거나 인덱스를 만들때 얻는 효율성보다 삽입, 갱신, 삭제로 인해 잃는
효율성이 더 큰 칼럼에는 인덱스를 만들면 안된다. 이러한 OPERATION은 인덱스를
유지하기 위한 필요 때문에 느려진다.

*UNIQUE 인덱스는 더 나은 선택성 때문에 NONUNIQUE 인덱스보다 좋다. PRIMARY
KEY 칼럼에 UNIQUE 인덱스를 사용한다. 그리고 FOREIGN KEY 칼럼과 WHERE 절
에서 자주 사용되는 칼럼에는 NONUNIQUE 인덱스를 사용한다.

5.가용한 인덱스 PATH를 만들어라

인덱스를 사용하기 위해서는 기술한 SQL문을 이용할 수 있는 식으로 SQL을 작
성하라. OPTIMIZER는 인덱스가 존재하기 때문에 인덱스를 사용하는 ACESS PATH
를 사용할 수 없다. 따라서 ACCESS PATH는 반드시 SQL이 사용할 수 있게 만들
어 져야 한다. SQL HINT를 사용하는 것은 인덱스 사용을 보증해주는 방법중 하
나이다. 특정 ACCESS PATH를 선택하기 위한 다음의 힌트를 참고 하라

6.가능하면 EXPLAIN과 TKPROF를 사용하라

만약 SQL문이 잘 다듬어지지 않았다면 비록 오라클 데이터베이스가 잘 짜여져
있어도 효율성이 떨어질 것이다. 이럴 경우 EXPLAIN TKPROF에 능숙해져야 한
다. EXPALIN PLAN은 SQL이 사용하는 ACCESS PATH를 발견할 수 있게 해주고
TKPROF는 실제 PERFORMANEC의 통계치를 보여준다. 이 TOOL은 오라클 서버 소
프트웨어에 포함되어 있고 SQL의 성능을 향상시켜 준다.

7.OPTIMIZER를 이해하라.

SQL은 RULE-BASED나 COST-BASED중 하나를 이용해서 기동된다.기존의 소
프트웨어는 RULE BASED 방식을 채택하고 있다. 그리고 많은 오라클 소프트웨
어가 이러한 방식을 오랫동안 사용해 왔다. 그러나 새로 출시된 소프트웨어에 대
해서는 COST BASED 방식의 OPTIMIZER를 고려해야 한다. 오라클은 새로 출
시되는 프로그램을 COST BASED방식으로 업그레이드 시켜왔으며 이러한 방식
은 시스템을 훨씬 더 안정적으로 만들었다. 만약 COST BASED방식의
OPTIMIZER를 사용한다면 반드시 ANALYZE 스키마를 정기적으로 사용해야 한
다. ANALYZE스키마는 데이터베이스 통계를 데이터 사전 테이블에 기록하는 역
할을 수행하며 그렇게 되면 COST BASED OPTIMIZER가 그것을 사용하게 된
다. SQL은 COST BASED OPTIMIZER를 사용할 때만 잘 조정될 수 있다. 만약
RULE BASED에서 COST BASED로 바꾸고 싶다면 데이터베이스를 사용하는 모
든 소프트웨어의 모든 SQL문의 성능을 평가해 보아야 한다.

8.지엽적으로 동작하더라도 전역적으로 생각하라

항상 주의할 것은 하나의 SQL문을 조정하기 위해 생긴 데이터베이스안의 변화
는 다른 응용프로그램이나 다른 사용자가 이용하는 다른 명령문에 영향을 미친다
는 사실이다.

9.WHERE절은 매우 중요하다.

비록 인덱스가 가용하다고 해도 다음의 WHERE 절은 그 인덱스 ACCESS PATH
를 사용하지 않는다.(즉 COL1 과 COL2는 같은 테이블에 있으며 인덱스는
COL1에 만들어진다.)

COL1 > COL2
COL1 < COL2
COL1 > = COL2
COL1 <= COL2
COL1 IS NULL
COL1 IS NOT NULL.

인덱스는 NULL값을 갖는 칼럼에는 ROWID를 저장하지 않는다. 따라서 NULL값
을 갖는 ROW를 검색할 때는 인덱스를 사용하지 못한다.

COL1 NOT IN (VALUE1, VALUE2 )
COL1 != EXPRESSION
COL1 LIKE ''%PATTERN''.

이럴 경우 THE LEADING EDGE OF THE INDEX(?) 는 작동되지 않고 인덱스가 사
용되지 못하게 한다. 한편 COL1 LIKE ''PATTERN %''이나 COL1 LIKE ''PATTERN %
PATTERN%'' 는 한정된 인덱스 스캔을 수행하기 때문에 인덱스를 사용할 수 있다.

NOT EXISTS SUBQUERY
EXPRESSION1 = EXPRESSION2.

인덱스된 컬럼을 포함하는 표현(EXPRESSION), 함수, 계산(CALCULATIONS)은 인덱스
를 사용하지 못한다. 다음의 예에서 보면 UPPER SQL 함수를 사용하면 인덱스
스캔을 사용할 수 없고 FULL TABLE SCAN으로 끝나고 만다.

SELECT DEPT_NAME
FROM DEPARTMENT
WHERE UPPER(DEPT_NAME) LIKE ''SALES%'';

10.레코드 필터링을 위해서는 HAVING보다는 WHERE를 사용하라

인덱스가 걸려있는 칼럼에는 GROUP BY와 같이 HAVING절을 사용하지 마라. 이 경
우 인덱스는 사용되지 않는다. 또한 WHERE절로 된 ROW를 사용하지 마라. 만약
EMP테이블이 DEPTID컬럼에 인덱스를 가지고 있다면 다음 질의는 HAVING 절을
이용하지 못한다.

SELECT DEPTID,
SUM(SALARY)
FROM EMP
GROUP BY DEPTID
HAVING DEPTID = 100;

그러나 같은 질의가 인덱스를 사용하기 위해 다시 씌여질 수 있다.

SELECT DEPTID,
SUM(SALARY)
FROM EMP
WHERE DEPTID = 100
GROUP BY DEPTID;

11. WHERE 절에 선행 INDEX 칼럼을 명시하라.

복합 인덱스의 경우, 선행 인덱스가 WHERE절에 명시되어 있다면 쿼리는
그 인덱스 를 사용할 것이다. 다음의 질의는 PART_NUM과 PRODUCT_ID 칼럼
에 있는 PRIMARY KEY CONSTRAINT에 기초한 복합 인덱스를 이용할 것이다.

SELECT *
FROM PARTS
WHERE PART_NUM = 100;

반면, 다음의 쿼리는 복합인덱스를 사용하지 않는다.

SELECT *
FROM PARTS
WHERE PRODUCT_ID = 5555;

같은 요청(REQUEST)이 인덱스를 이용하기 위해 다시 씌어 질 수 있다. 다음 질의
의 경우, PART_NUM컬럼은 항상 0 보다 큰 값을 가질것이다.

SELECT *
FROM PARTS
WHERE PART_NUM > 0
AND PRODUCT_ID = 5555;

12.인덱스 SCAN과 FULL TABLE SCAN을 평가하라.

한 행(ROW)의 15% 이상을 검색하는 경우에는 FULL TABLE SCAN이 INDEX
ACESS PATH보다 빠르다. 이런 경우, SQL이 FULL TABLE SCAN을 이용할 수 있도록
여러분 스스로 SQL을 작성하라. 다음의 명령문은 비록 인덱스가 SALARY
COLUMN에 만들어져 있어도 인덱스 SCAN을 사용하지 않을 것이다. 첫 번째 SQL
에서, FULL HINT를 사용한다면 오라클은 FULL TABLE SCAN을 수행할 것이다. 인덱
스의 사용이 나쁜 점이 더 많다면 아래의 기술을 이용해서 인덱스 수행을 막을
수 있다.

SELECT * --+FULL
FROM EMP
WHERE SALARY = 50000;

SELECT *
FROM EMP
WHERE SALARY+0 = 50000;

다음의 명령문은 비록 인덱스가 SS# COLUMN에 있어도 인덱스 SCAN을 사용하
지 않을 것이다.

SELECT *
FROM EMP
WHERE SS# || '' '' = ''111-22-333'';

오라클이 불분명한 데이터 변환을 수행해야 하는 경우 인덱스가 항상 사용되지
않는 것은 아니다. 다음의 예를 보면, EMP 칼럼에 있는 SALARY는 숫자형 칼
럼이고 문자형이 숫자값으로 변환된다.

SELECT *
FROM EMP
WHERE SALARY = ''50000'';

테이블의 행이 15%이거나 그보다 작을 경우 인덱스 스캔은 보다 잘 수행 될 것
이다. 왜냐 하면 인덱스 스캔은 검색된 행(ROW)하나 하나 마다 다중의 논리적인
읽기 검색(READ)을 할 것이기 때문이다. 그러나 FULL TABLE SCAN은 하나의 논리적
인 읽기 검색 영역 안의 BLOCK에 있는 모든 행들을 읽을 수 있다. 그래서 테이
블의 많은 행들에 접근해야 하는 경우에는 FULL TABLE SCAN이 낫다. 예로 다음의
경우를 보자. 만약 EMP TABLE과 그 테이블의 모든 인덱스에 대해 ANALYZE라
는 명령어가 수행된다면, 오라클은 데이터 사전인 USER_TABLES와
USER_INDEXES에 다음과 같은 통계치를 산출해 낸다.

TABLE STATISTICS:
NUM_ROWS = 1000
BLOCKS = 100

INDEX STATISTICS:

BLEVEL = 2
AVG_LEAF_BLOCKS_PER_KEY = 1
AVG_DATA_BLOCKS_PER_KEY = 1

이러한 통계치 에 근거해서, 아래에 보이는 것이 각각의 다른 SCAN에 대한 논리
적인 읽기(READ)-즉 ACESS된 BLOCK이 될 것이다.

USE OF INDEX TO RETURN ONE ROW = 3

(BLEVEL+(AVG_LEAF_BLOCKS_PER_KEY - 1) +
AVG_DATA_PER_KEY

FULL TABLE SCAN = 100
(BLOCKS)

USE OF INDEX TO RETURN ALL ROWS = 3000
(NUM_ROWS * BLOCKS ACCESSED TO RETURN ONE ROW USING INDEX)

13. 인덱스 스캔에 ORDER BY를 사용하라

오라클의 OPTIMIZER는 , 만약 ORDER BY라는 절이 인덱스된 칼럼에 있다면 인
덱스 스캔을 사용할 것이다. 아래의 질의는 이러한 점을 보여 주는 것인데 이 질
의는 비록 그 칼럼이 WHERE 절에 명시되어 있지 않다고 해도 EMPID컬럼에 있
는 가용한 인덱스를 사용할 것이다. 이 질의는 인덱스로부터 각각의 ROWID를
검색하고 그 ROWID를 사용하는 테이블에 접근한다.

SELECT SALARY
FROM EMP
ORDER BY EMPID;

만약 이 질의가 제대로 작동하지 않는다면, 당신은 위에서 명시되었던 FULL HINT
를 사용하는 같은 질의를 다시 작성함으로써 다른 대안들을 이용해 볼 수 있다.

14. 자신의 데이터를 알아라

내가 이미 설명한 것처럼, 당신은 당신의 데이터를 상세하게 알고 있어야 한다.
예를 들어 당신이 BOXER라는 테이블을 가지고 있고 그 테이블이 유일하지 않은
인덱스를 가진 SEX라는 컬럼과 BOXER_NAME이라는 두 개의 테이블을 가지고 있
다고 가정해 보자. 만약 그 테이블에 같은 수의 남자, 여자 복서가 있다면 오라
클이 FULL TABLE SCAN을 수행하는 경우 다음의 질의가 훨씬 빠를 것이다.

SELECT BOXER_NAME
FROM BOXER
WHERE SEX = ''F'';

당신은 다음과 같이 기술함으로써 질의가 FULL TABLE SCAN을 수행하는지를 확실
하게 해 둘 수 있다.

SELECT BOXER_NAME --+ FULL
FROM BOXER
WHERE SEX = ''F'';

만약 테이블에 980 명의 남성 복서 데이터가 있다면, 질의는 인덱스 SCAN으로
끝나기 때문에 아래형식의 질의가 더 빠를 것이다.

SELECT BOXER_NAME --+ INDEX (BOXER BOXER_SEX)
FROM BOXER
WHERE SEX = ''F'';

이 예는 데이터의 분포에 대해 잘 알고 있는 것이 얼마나 중요한 가를 예시해 준
다. 데이터가 많아지고(GROW) 데이터 분포가 변화하는 것처럼 SQL 도 매우 다
양할 것이다. 오라클은 OPTIMIZER 가 테이블에 있는 데이터의 분포를 잘 인식하
고 적절한 실행 계획을 선택하도록 하기 위해 오라클 7.3 에 HISTOGRAMS라는
기능을 추가했다.

15. KNOW WHEN TO USE LARGE-TABLE SCANS.

작거나 큰 테이블에서 행들을 추출할 때, 전체 테이블의 검색은 인텍스를 사용한
검색보다 성능이 더 좋을 수도 있다. 매우 큰 테이블의 인덱스 검색은 수많은
인덱스와 테이블 블록의 검색이 필요할수도 있다. 이러한 블록들이 데이터베이
스 버퍼 캐쉬에 이동되면 가능한한 오래도록 그곳에 머무른다. 그래서 이러한
블록들이 다른 질의등에 필요하지 않을 수도 있기 때문에, 데이터베이스 버퍼 히
트 비율이 감소하며 다중 사용자 시스템의 성능도 저하되기도 한다. 그러나 전
체 테이블 검색에 의해서 읽혀진 블록들은 데이터베이스 버퍼 캐쉬에서 일찍 제
거가 되므로 데이터베이스 버퍼 캐쉬 히트 비율은 영향을 받지 않게 된다.

16. MINIMIZE TABLE PASSES.

보통, SQL질의시 참조하는 테이블의 숫자를 줄임으로 성능을 향상시킨다. 참조
되는 테이블의 숫자가 적을수록 질의는 빨라진다. 예를 들면 NAME, STATUS,
PARENT_INCOME, SELF_INCOME의 네개의 컬럼으로 이루어진 학생 테이블
에서 부모님에 의존하는 학생과 독립한 학생의 이름과 수입에 대해서 질의시, 이
학생 테이블을 두번 참조하여 질의하게 된다..
SELECT NAME, PARENT_INCOME
FROM STUDENT
WHERE STATUS = 1
UNION
SELECT NAME, SELF_INCOME
FROM STUDENT
WHERE STATUS = 0;
( NAME이 프라이머리 키이며, STATUS는 독립한 학생의 경우는 1, 부모님에
의존적인 학생은 0으로 표시한다)
위의 같은 결과를 테이블을 두번 참조하지 않고도 질의 할 수 있다.

SELECT NAME,PARENT_INCOME*STATUS + SELF_INCOME(1-STATUS)
FROM STUDENT;

17. JOIN TABLES IN THE PROPER ORDER.

다수의 테이블 조인시 테이블들의 조인되는 순서는 매우 중요하다. 전반적으로,
올바른 순서로 테이블이 조인되었다면 적은 수의 행들이 질의시 참조된다. 언제
나 다수의 조인된 테이블들을 질의시 우선 엄격하게 조사하여 행들의 숫자를 최
대한으로 줄인다. 이러한 방법으로 옵티마이저는 조인의 차후 단계에서 적은 행
들을 조사하게 된다. 뿐만 아니라, 여러 조인을 포함하는 LOOP JOIN에서는 가
장 먼저 참조되는 테이블(DRIVING TABLE)이 행들을 최소한으로 리턴하도록 해야
한다. 그리고, 마스터와 상세 테이블 조인시에는(예를 들면 ORDER & ORDER
LINE ITEM TABLES) 마스터 테이블을 먼저 연결 시켜야 한다.
규칙에 근거한 옵티마이저의 경우에는 FROM CLAUSE의 마지막 테이블이 NESTED
LOOP JOIN의 DRIVING TABLE이 된다. NESTED LOOP JOIN이 필요한 경우에는
LOOP의 안쪽의 테이블에는 인텍스를 이용하는 것을 고려할 만하다. EXPLAIN
PLAN과 TKPROF는 조인 타입, 조인 테이블 순서, 조인의 단계별 처리된 행들
의 숫자들을 나타낸다.
비용에 근거한 옵티마이저의 경우에는 WHERE CLAUSE에 보여지는 테이블의 순
서는 옵티마이저가 가장 최적의 실행 계획을 찾으려고 하는 것과 상관 없다. 조
인되는 테이블의 순서를 통제하기 위해서 ORDERED HINT를 사용하는 것이 낫다.

SELECT ORDERS.CUSTID, ORDERS.ORDERNO,
ORDER_LINE_ITEMS.PRODUCTNO --+ORDERED
FROM ORDERS, ORDER_LINE_ITEMS
WHERE ORDERS.ORDERNO = ORDER_LINE_ITEMS.ORDERNO;

18. USE INDEX-ONLY SEARCHES WHEN POSSIBLE.

가능하다면, 인덱스만을 이용하여 질의를 사용하라. 옵티마이저는 오직 인덱스만
을 찾을 것이다. 옵티마이저는 SQL을 만족시키는 모든 정보를 인덱스에서 찾을
수 있을 때, 인덱스만을 이용할 것이다. 예를들면, EMP테이블이 LANME과
FNAME의 열에 복합 인덱스를 가지고 있다면 다음의 질의는 인덱스만은 이용할
것이다.

SELECT FNAME
FROM EMP
WHERE LNAME = ''SMITH'';

반면에 다음의 질의는 인덱스와 테이블을 모두 참조한다.

SELECT FNAME , SALARY
FROM EMP
WHERE LNAME = ''SMITH'';

19. REDUNDANCY IS GOOD.

WHERE CLAUSE에 가능한한 많은 정보를 제공하라. 예를 들면 WHERE COL1 =
COL2 AND COL1 = 10이라면 옵티마이저는 COL2=10이라고 추론하지만,
WHERE COL1 = COL2 AND COL2 = COL3이면 COL1=COL3이라고 초론하지는
않는다.

20. KEEP IT SIMPLE, STUPID.

가능하면 SQL문을 간단하게 만들라. 매우 복잡한 SQL문은 옵티마이저를 무력
화시킬 수도 있다. 때로는 다수의 간단한 SQL문이 단일의 복잡한 SQL문보다
성능이 좋을 수도 있다. 오라클의 비용에 근거한 옵티마이저는 아직은 완벽하지
않다. 그래서 EXPLAIN PLAN에 주의를 기울여야 한다. 여기서 비용이란 상대적인
개념이기에 정확히 그것이 무엇을 의미하는지 알지 목한다. 하지만 분명한 것은
적은 비용이 보다 좋은 성능을 의미한다는 것이다.
종종 임시 테이블을 사용하여 많은 테이블들을 포함하는 복잡한 SQL 조인을 쪼
개는 것이 효율적일 수도 있다. 예를 들면, 조인이 대량의 데이터가 있는 8개의
테이블을 포함할 때, 복잡한 SQL을 두 세개의 SQL로 쪼개는 것이 낫을 수 있
다. 각각의 질의는 많아야 네개정도의 테이블들을 포함하며 그 중간 값을 저장
하는 것이 낫을 수 있다.

21. YOU CAN REACH THE SAME DESTINATION IN DIFFERENT WAYS.

많은 경우에, 하나 이상의 SQL문은 의도한 같은 결과를 줄 수 있다. 각각의
SQL은 다른 접근 경로를 사용하며 다르게 수행한다. 예를들면, MINUS(-) 산술
자는 WHERE NOT IN (SELECT ) OR WHERE NOT EXISTS 보다 더 빠르다.
예를들면, STATE와 AREA_CODE에 각각 다른 인덱스가 걸려 있다. 인덱스에
도 불구하고 다음의 질의는 NOT IN의 사용으로 인해 테이블 전체를 조사하게
된다.
SELECT CUSTOMER_ID
FROM CUSTOMERS
WHERE STATE IN (''VA'', ''DC'', ''MD'')
AND AREA_CODE NOT IN (804, 410);

그러나 같은 질의가 다음 처럼 쓰여진다면 인덱스를 사용하게 된다
SELECT CUSTOMER_ID
FROM CUSTOMERS
WHERE STATE IN (''VA'', ''DC'', ''MD'')
MINUS
SELECT CUSTOMER_ID
FROM CUSTOMERS
WHERE AREA_CODE IN (804, 410);

WHERE절에 OR을 포함한다면 OR대신에 UNION을 사용할 수 있다. 그래서,
SQL 질의를 수행하기 전에 먼저 실행계획을 조심스럽게 평가해야 한다. 이러한
평가는 EXPLAIN PLAN AND TKPROF를 이용하여 할 수 있다.

22. USE THE SPECIAL COLUMNS.

ROWID AND ROWNUM 열을 이용하라. ROWID를 이용하는 것이 가장 빠르다.
예를들면, ROWID를 이용한 UPDATE는 다음과 같다.

SELECT ROWID, SALARY
INTO TEMP_ROWID, TEMP_SALARY
FROM EMPLOYEE;

UPDATE EMPLOYEE
SET SALARY = TEMP_SALARY * 1.5
WHERE ROWID = TEMP_ROWID;

ROWID값은 데이터베이스에서 언제나 같지는 않다. 그래서, SQL이나 응용 프
로그램이용시 ROWID값을 절대화 시키지 말라. 리턴되는 행들의 숫자를 제한
시키기위해 ROWNUM을 이용하라. 만약에 리턴되는 행들을 정확히 모른다면
리턴되는 행들의 숫자를 제한하기위해 ROWNUM을 사용하라
다음의 질의는 100개 이상의 행들을 리턴하지는 않는다.
SELECT EMPLOYE.SS#, DEPARTMENT.DEPT_NAME
FROM EMPLOYEE, DEPENDENT
WHERE EMPLOYEE.DEPT_ID = DEPARTMENT.DEPT_ID
AND ROWNUM < 100;

23.함축적인 커서대신 명시적인 커서를 사용하라.

함축적 커서는 여분의 FETCH를 발생시킨다. 명시적 커서는 DECLARE, OPEN,
FETCH와 CLOSE CURSOR문을 사용하여 개발자에 의해서 생성된다. 함축 커서는
DELETE, UPDATE, INSERT와 SELECT문을 사용하면 오라클에 의해서 생성
된다.

24.오라클 병렬 쿼리 옵션을 찾아서 이용하라.

병렬 쿼리 옵션을 사용하면, 보다 빠른 성능으로 SQL을 병렬로 실행할 수 있다.
오라클 7에서는, 오직 FULL TABLE SCAN에 기반한 쿼리만이 병렬로 수행될 수 있다.
오라클 8에서는, 인덱스가 분할되어있다면 INDEXED RANGE SCANS에 기반한 쿼리도
병렬로 처리될 수 있다. 병렬 쿼리 옵션은 다수의 디스크 드라이버를 포함하는
SMP와 MPP SYSTEM에서만 사용될 수 있다.

오라클 서버는 많은 우수한 특성을 가지고 있지만, 이러한 특성의 존재만으로는
빠른 성능을 보장하지 않는다. 이러한 특성을 위해서 데이터베이스를 조정해야하
며 특성을 이용하기 위해 특별하게 SQL을 작성해야 한다. 예를 들면, 다음의
SQL은 병렬로 수행될 수 있다.

SELECT * --+PARALLEL(ORDERS,6)
FROM ORDERS;

25.네트웍 소통량을 줄이고 한번에 처리되는 작업량을 늘려라.

ARRAY PROCESSING과 PL/SQL BLOCK을 사용하면 보다 나은 성능을 얻을 수 있고
네트웍 소통량을 줄인다. ARRAY PROCESSING은 하나의 SQL문으로 많은 ROW를 처
리할 수 있게 한다. 예를 들면, INSERT문에서 배열을 사용하면 테이블내의
1,000 ROW를 삽입할 수 있다. 이러한 기술을 사용하면 주요한 성능 향상을 클라
이언트/서버와 배치시스템에서 얻어질 수 있다.

복합 SQL문은 과도한 네트웍 소통을 유발할 수 있다. 그러나 만일 SQL문이 단
일 PL/SQL 블록안에 있다면, 전체 블록은 오라클 서버에 보내져서 그곳에서 수
행되고, 결과는 클라이언트의 APPLICATION에게 돌아온다.

개발자와 사용자는 종종 SQL을 데이터베이스에서 데이터를 검색하고 전송하는
간단한 방법으로 사용한다. 때때로 직접적으로 SQL을 작성하지 않고 코드 발생
기를 사용하여 작성한 APPLICATION은 심각한 성능 문제를 일으킨다. 이러한 성능
감퇴는 데이터베이스가 커지면서 증가한다.

SQL은 유연하기 때문에, 다양한 SQL문으로 같은 결과를 얻을 수 있다. 그러나
어떤 문은 다른 것보다 더 효율적이다. 여기에 기술된 팁과 기법을 사용하면 빠
르게 사용자에게 정보를 제공할 수 있는 APPLICATION과 리포트를 얻을 수 있다.


반응형
준비물

1. 윈도우 XP SP2 이상, 윈도우 비스타 SP1 (기타 운영체제는 차후에 지원한답니다.)
2. JDK 1.5.0_11 이상
3. Eclipse Basic 3.4.1 혹은 Eclipse IDE for Java Developers 혹은 Eclipse IDE Java EE Developers ( <- 이녀석이 추천작)
4. .Net Framework 3.5 이상
5. 실버라이트 2 런타임(2.0.31005.0 이상)
6. 실버라이트2 SDK


JDK의 설치

java.sun.com 으로 가서 jdk 를 설치합니다.


다운로드를 선택하십니다.


SE 버전을 다운 받습니다. EE 버전도 상관없을것 같습니다.



저는 64비트 윈도우를 사용하므로 x64 를 선택했습니다.


다운받고 설치합니다.

설치경로는 알고 계셔야 합니다.(이클립스 세팅할때 필요합니다)


이클립스의 설치

우선 http://www.eclipse.org 사이트로 가서 이클립스를 다운받습니다.

(※ 64 비트 윈도우 사용자는 다음의 경로에서 다운받습니다. http://download.eclipse.org/eclipse/downloads/
64비트 이클립스 빌드는 따로 있습니다.
Windows (x86_64
) 버전으로 다운 받습니다.
물론 OS, JDK 가 모두 64비트여야 합니다.
)

오랜만에 와봤더니 홈페이지가 바뀌었군요.



적당한 녀석을 다운 받습니다.

저는 EE버전을 추천합니다.


그 다음에 나오는 미러는 대충 아무데나 선택하시면 됩니다.



이클립스는 설치 프로그램이 별도로 없고 그냥 압축을 풀면 바로 사용할 수 있는 형태로 되어 있습니다.

압축을 풀어보면 다음과 같은 모습이 됩니다.



이제 이클립스 폴더를 적절한 곳으로 옮기고 바탕화면에 단축아이콘을 만든뒤 실행해봅니다.


자바환경변수를 안잡아서 그렇습니다.

아까 JDK 설치한 경로를 기억해두시고 환경변수를 설정합니다.








아래에는 아까 설치하였던 경로를 입력합니다.

저의 경우는 아래와 같군요.


마찬가지 방법으로 CLASSPATH 를 만들어 넣습니다.


이제 실행하면 이클립스가 잘 실행됩니다.



닷넷프레임워크, 실버라이트런타임, 실버라이트 sdk 설치

이 부분은 그냥 다운 받아 실행하시면 되므로 길게 설명 안하겠습니다.

닷넷프레임워크 3.5  :  http://www.microsoft.com/downloads/details.aspx?FamilyID=333325fd-ae52-4e35-b531-508d977d32a6&DisplayLang=en

실버라이트개발자용 런타임 : http://go.microsoft.com/fwlink/?LinkID=119972

실버라이트 SDK : http://www.microsoft.com/downloads/details.aspx?FamilyId=8D933343-038F-499C-986C-C3C7E87A60B3&displaylang=en


서비스팩은 필수사항으로 나와있지는 않지만 설치하시기를 강력하게 주장하는 바입니다. -_-;;

닷넷프레임워크 3.5 서비스팩 1 : http://www.microsoft.com/downloads/details.aspx?familyid=AB99342F-5D1A-413D-8319-81DA479AB0D7&displaylang=en


이클립스 플러그인의 설치

이클립스에서 Help -> Software Update 를 선택합니다.


Available Software 탭을 선택하신후 Add Site... 를 선택합니다.


Location 에 http://www.eclipse4sl.org/update/  를 입력하고 ok를 누릅니다.


이제 리스트가 나타나면 좌측에서 Eclipse Tools for Microsoft SIlverlight 를 선택하고 인스톨을 누릅니다.

(※ 만일 EE 버전이 아닌 Basic 등의 버전을 다운 받으셨다면
RCP 가 설치되어 있나 반드시 확인하시고 만일 설치되어 있지 않다면
RCP 를 먼저 설치하시고 eclipse4sl 을 설치하셔야 합니다.
RCP 를 나중에 설치하시게 된다면 eclipse4sl 을 지우고 RCP 설치후
재설치하셔야 합니다.
)


이제 프로그램을 다운받고 계약서에 동의하나면 설치를 시작합니다.



리스타트해야된다고 합니다.

리스타트 하면 잘 뜹니다.


이제 파일메뉴에서 New->Project 를 선택합니다.



귀여운 녀석 저 아래에 있군요.

이렇게 해서 프로젝트르 짜짠 만들면

실버라이트 프로젝트가 예쁘게 나옵니다.



하지만 중대한 문제가 있는데 말이죠...

64비트 시스템에서는 XAML 에디터가(Visual Editor for Silverlight) 정상적으로 작동하지 않는것 같습니다. -_-;;

32비트 시스템에서는 문제 없는것 같으니 참고하시고요.


당분간은 이클립스를 이용한 개발을 하시려면

Expression Blend 와 병행하시는것이 좋을듯합니다.



실행은 잘되는군요...

당연히 되야되는것이겠지만..

실버라이트 컴파일러도 잘 작동하는듯합니다.


반응형

시작하기 전에

새로운 기능을 알아보기 전에 윈도 운영체제 사용자들이 겪을 치명적인 문제를 포함한 몇 가지 문제점과 가능한 해결책을 간략히 알아본다.

  1. 이클립스가 실행 되지 않는 문제

    다운받은 가니메데 배포판의 종류에 따라서 ECLIPSE_HOME/eclipse.ini 파일에 기록된 메모리 크기 관련 설정값이 다르다. 보통은 윈도 버전의 이 클립스에서 메모리 부족 때문에 나타나는 현상으로 Java EE 버전이나 플러그인 개발 버전을 다운 받았다면, eclipse.ini 파일의 -Xmx512m를 – Xmx256으로 수정한다.

  2. 한글 깨짐 현상

    일부 영문 전용 폰트에서 한글 깨짐 현상이 발생한다. 대표적으로 많은 개발자의 사랑을 받고 있는 ‘Bitstream Vera Sans Mono’을 이용하면 문제를 확인할 수 있다. 임시방편으로 영문 전용 폰트에 한글 폰트를 추가해 새로운 폰트를 만들어 사용하는 방법이 있다.

 

자바 개발환경 개선사항

새로운 리팩터링

자바 리팩터링에 ‘Extract Class(클래스 추출)’가 추가됐다. Extract Class는 한 클래스가 너무 많은 책임을 수행할 때, 책임을 다른 클래스로 분리하는 리팩터링이다.

리팩터링 책의 예제를 활용해보자. <리스트 1>은 리팩터링 전의 Person 클래스로 간단하지만 개인 정보와 연락처 정보 관리라는 두 가지 책임을 가진다. Extract Class로 연락처 관리의 책임을 추출해보자.

 

<리스트 1>Extract Class 리팩터링을 적용하기 전 Person 클래스

  1. package refactoring;  
  2.   
  3. public class Person {  
  4.   private String name;  
  5.   private String officeAreaCode;  
  6.   private String officeNumber;  
  7.   
  8.   public String getName() {  
  9.    return name;  
  10.   }  
  11.   
  12.   public void setName(String name) {  
  13.    this.name = name;  
  14.   }  
  15.   
  16.   public String getOfficeAreaCode() {  
  17.    return officeAreaCode;  
  18.   }  
  19.   
  20.   public void setOfficeAreaCode(String officeAreaCode) {  
  21.    this.officeAreaCode = officeAreaCode;  
  22.   }  
  23.   
  24.   public String getTelephoneNumberNumber() {  
  25.    return "( " + officeAreaCode + ") "+ officeNumber;  
  26.   }  
  27.   
  28.   public String getOfficeNumber() {  
  29.    return officeNumber;  
  30.   }  
  31.   
  32.   public void setOfficeNumber(String officeNumber) {  
  33.    this.officeNumber = officeNumber;  
  34.   }  
  35. }  

 

먼저 Extract Class 메뉴를 선택한다. 최상단 메뉴나 <화면 1>과 같이 편집기 의 오른쪽 마우스 컨텍스트 메뉴에서 Refactor -> Extract Class를 선택한다.

 

<화면 1>Extract Class 메뉴 선택

 

Extract Class 메뉴를 선택하면 <화면 2>와 같이 설정 다이얼로그가 나온다. 설정 다이얼로그에서는 추출 대상 필드를 선택하고, 추출할 클래스 이름과 추출한 클래스의 객체를 참조할 필드 이름을 지정한다. 여기서는 연락처 정보와 관련된 officeAreaCode와 officeNumber 필드를 Telephone 클래스로 추출한다. Person 클래스가 참조하는 Telephone 클래스 인스턴스의 이름은 telephone으로 설정한다.

 

<화면 2>Extract Class 설정 다이얼로그

 

<리스트 2>와 <리스트 3>의 코드 로 리팩터링되었다. 위에서 선택한 두 필드를 가지고 있는 Telephone 클래스가 생성되었고, Person 클래스는 Telephone 클래스의 인스턴스를 필드로 가지고 이를 참조하도록 변경되었다. 이클립스가 자동으로 처리해주는 리팩터링 기능에서 특히 클래스간의 관계를 다루는 리팩터링에 대한 처리가 미흡한 편인데 편리한 리팩터링이 하나 더 추가되었다.

 

<리스트 2>Extract Class 리팩터링 적용 후 Person 클래스

  1. package refactoring;  
  2.   
  3. public class Person {  
  4.     private String name;  
  5.     private Telephone telephone = new Telephone();  
  6.   
  7.     public String getName() {  
  8.         return name;  
  9.     }  
  10.      
  11.     public void setName(String name) {  
  12.         this.name = name;  
  13.     }  
  14.      
  15.     public String getOfficeAreaCode() {  
  16.         return telephone.getOfficeAreaCode();  
  17.     }  
  18.      
  19.     public void setOfficeAreaCode(String officeAreaCode) {  
  20.         this.telephone.setOfficeAreaCode(officeAreaCode);  
  21.     }  
  22.      
  23.     public String getTelephoneNumberNumber() {  
  24.         return "( " + telephone.getOfficeAreaCode() + ") "+ telephone.getOfficeNumber();  
  25.     }  
  26.      
  27.     public String getOfficeNumber() {  
  28.         return telephone.getOfficeNumber();  
  29.     }  
  30.      
  31.     public void setOfficeNumber(String officeNumber) {  
  32.         this.telephone.setOfficeNumber(officeNumber);  
  33.     }  
  34. }  

 

<리스트 3>Extract Class 리팩터링 적용 후 Telephone 클래스

  1. package refactoring;  
  2.   
  3. public class Telephone {  
  4.     private String officeAreaCode;  
  5.     private String officeNumber;  
  6.   
  7.     public Telephone() {  
  8.     }  
  9.   
  10.     public String getOfficeAreaCode() {  
  11.         return officeAreaCode;  
  12.     }  
  13.   
  14.     public void setOfficeAreaCode(String officeAreaCode) {  
  15.         this.officeAreaCode = officeAreaCode;  
  16.     }  
  17.   
  18.     public String getOfficeNumber() {  
  19.         return officeNumber;  
  20.     }  
  21.   
  22.     public void setOfficeNumber(String officeNumber) {  
  23.         this.officeNumber = officeNumber;  
  24.     }  
  25. }  

 

Breadcrumb

자바 편집기 영역에 추가된 기능 중 단연 돋보이는 기능은 ‘Breadcrumb’다. 노트북 등 화면이 크지 않은 환경에서 개발할 때는 편집기 영역을 최대화(커맨드 + M)해서 작업하는 경우가 많은데, Breadcrumb를 통해 현재 위치를 한눈에 볼 수 있고, 편집기의 최대화를 해제하고 ‘Package Explorer (패키지 탐색기)’등을 이용해서 다른 파일을 열어야 하는 불편함을 해소한다.

사용법은 정말 간단한데 화면 상단 툴바의 ‘Toggle Breadcrumb’를 선택하거나, <화면 3>과 같이 편집기의 컨텍스트 메뉴 중 ‘Show in Breadcrumb’를 선택하면 된다. 컨텍스트 메뉴에서 Breadcrumb를 비활성화 시킬 수 있는 방법은 없으니 참고하자. Breadcrumb를 비활성화 시키려면 상단 툴바의 토글 버튼을 이용하자.

 

<화면 3> Breadcrumb 활성화

 

Breadcrumb가 활성화되면 <화면 4>와 같이 편집기 상단에 현재 위치를 표시해주는 표시영역이 생긴다. 이 영역을 통해 최대화 상태의 편집기에서도 현재 위치를 한눈에 볼 수 있고, 최대화 상태에서도 편리하게 다른 파일을 열 수 있다.

<화면 4>Breadcrumb의 활성화와 다른 클래스로 이동하기

 

향상된 Call Hierarchy

이클립스를 사용하는 자바 개발자에게 인기 좋은 기능 중 하나가 ‘Call Hierarchy (호출 계층)’를 살펴보는 기능으로 호출 관계가 복잡한 함수의 호출 관계를 트리 구조로 보여준다. 이클립스 3.3까지는 호출자(caller)를 찾을 때, 특정 함수나 생성자를 사용하고 있는 함수를 찾는 기능만을 제공했다.

이 정도로도 편리한 기능이지만 코드에 존재하지 않는 기본 생성자를 호출해서 객체를 생성하는 위치를 찾으려면, 기본 생성자를 코드에 추가해서 찾아야 하는 단점이 있었다. 또, 상수나 필드를 사용하는 위치를 찾는 기능은 없기 때문에 검색 기능을 이용해서 찾아야 하는 불편함이 있었다.

이클립스 3.4에서는 클래스를 선택하고 ‘Call Hierarchy’를 찾아보면(CTRL + ALT + H) 모든 생성자를 호출하는 위치를 찾아준다. 기본 생성자가 코드 상에 존재하지 않아도 찾아주니 편리하다. 또, 상수나 필드를 사용하는 위치도 ‘Call Hierarchy’를 통해 보여주니 더 이상 불편하게 검색하지 않아도 된다. <화면 5>과 같이 모든 생성자와 상수에 대한 호출 계층을 확인할 수 있다.

 

hierarchy1.jpg

hierarchy2.jpg

 <화면 5>향상된 Call Hierarchy. 모든 생성자의 호출 위치(상단)과 필드나 상수의 사용 위치(하단)를 확인할 수 있다.

실행 가능한 JAR 파일 내보내기

기존의 이클립스의 내보내기(Export) 기능에 실행 가능한 JAR(Runnable JAR) 파일을 내보낼 수 있는 기능이 추가되었다. 이를 통해 자바 실행 환경(Java Runtime Environment, JRE)이 설치 되었다면 JAR 파일을 더블클릭하는 것만으로 애플리케이션을 실행할 수 있다.

<리스트 4>는 “Hello Ganymede!”라는 메시지를 화면에 출력하는 단순한 자바 스윙 애플리케이션이다. 이 예제를 실행 가능한 형태의 JAR 파일로 배포해보자.

 

<리스트 4> main() 함수를 가지는 단순한 스윙 예제

  1. package runnable;  
  2.   
  3. import javax.swing.JFrame;  
  4. import javax.swing.JLabel;  
  5.   
  6. public class HelloSwing extends JFrame {  
  7.   
  8.   public HelloSwing() {  
  9.    setTitle("Eclipse 3.4 Ganymede");  
  10.    getContentPane(). add(new JLabel("Hello Ganymede!"));  
  11.    setSize(250, 100);  
  12.   }  
  13.   
  14.   public static void main(String[] args) {  
  15.   new HelloSwing().setVisible(true);  
  16.   }  
  17. }  

 

<화면 6> 실행 가능한 JAR 파일 내보내기

‘File -> Export -> Java -> Runnable JAR file’옵션을 통해 실행 가능한 JAR 파일을 생성할 수 있다. 먼저, Launch Configuration 중에서 JAR 파일을 생성할 대상을 선택한다. 선택한 대상이 MANIFEST.MF 파일에서 Main-Class로 이용된다. 대상 경로와 파일이름을 선택하면 실행 가능한 파일을 생성한다. 생성된 JAR 파일을 더블클릭하면 <화면 7>과 같이 애플리케이션이 실행된다.

 

<화면 7>JAR로 실행한 애플리케이션

 

<리스트 5>와 같이 자동 생성된 MANIFEST.MF 파일 은 이전에도 사용자가 직접 작성할 수 있었다. 하지만 이클립스는 단지 MANIFEST.MF 파일을 자동 생성해주는 기능 이상을 제공한다.

 

<리스트 5>자동 생성된 MANIFEST.MF 파일

  1. Manifest-Version: 1.0  
  2. Class-Path: .  
  3. Main-Class: runnable.HelloSwing  

 

예제는 외부 라이브러리를 사용하지 않으니 그리 복잡하지 않지만, 만약 애플리케이션을 구동하는 데 수많은 이클립스 프로젝트에 대한 참조와 라이브러리 파일이 필요하다면 사용자가 직접 작업하기에는 꽤나 복잡해진다. 그래서 이클립스의 실행 가능한 JAR파일 생성 기능은, 참조하는 프로젝트의 모든 클래스 파일과 포함된 모든 라이브러리의 압축을 해제한 클래스 파일을 함께 묶어주는 기능을 제공한다. 사용자는 압축을 해제한 형태로 라이브러리를 재배포하는 것이 라이센스를 위반 하는지만 주위를 기울이면 된다.

 

Outline 화면에서 코드 재배열하기

개요(Outline) 화면에서 코드의 구성 요소의 위치를 재배열 할 수 있는 기능이 이클립스 3.4에 조용히 추가되었다. 작업 중 추가한 한 뭉치의 코드에서 구성 요소간의 순서가 마음에 들지 않으면 하나씩 잘라내서 원하는 위치에 붙여넣는 작업을 반복하게 된다. 이제 개요 화면 에서 한눈에 전체 구조를 보면서 드래그 앤 드롭 기능을 이용해서 코드를 재배열 할 수 있다. <화면 8>에서 자바 메서드의 드래그 앤 드롭을 통한 위치 이동을 보여준다.

 outline1.jpg

outline2.jpg

<화면 8> Outline에서 구성 요소의 드래그 앤 드롭

 

이때, Outline의 자동 정렬 기능 을 이용 중이라면 드래그 앤 드롭은 동작하지 않는다. 특정 요소의 위치를 옮길 때 요소와 요소 사이의 빈 줄 삽입 여부가 의도한 대로 처리되지 않을 수 있으니 처리가 필요하다면 주의하자. Outline에서의 재배치 기능은 자바 에디터뿐 아니라 XML 에디터에서도 지원한다. 앞으로 다양한 에디터 환경에서 지원할 것으로 기대된다.

 

리치 호버

특정 요소 위에 마우스를 가져다 두면 나타나는 JavaDoc 설명을 보여주는 것과 같은 호버 기능이 향상되었다. JavaDoc 호버는 <화면 9>의 상단 화면과 같이 JavaDoc 화면에서 보기, 외부 브라우저에서 보여주기 등 더 풍부한 기능을 제공한다. 리치 호버 기능이 정말 유용하게 사용되는 때는 디버그 상황에서다. <화면 9>의 하단 화면에서 볼 수 있듯이 복잡한 자료구조에 대한 값도 한 눈에 볼 수 있는 기능을 제공한다. 예전처럼 Variables 화면을 뒤지거나, Expressions 화면에 표현식을 입력해 봐야 하는 불편함이 해소되었다.

 hover1.jpg

hover2.jpg

<화면 9> 향상된 호버 기능. JavaDoc 호버(상단)와 디버거 호버(하단)

 

저장 기본 동작 정의

아무리 팀에서 코드 형식을 정해놓고, 이클립스 자동 포맷에 맞춰서 만들어 두어도 자신만의 스타일에 익숙하다면 종종 잊어버리곤 한다. 또, 개발과정 중에 사용하다 남은 불필요한 Import 잔재를 한번에 없애고 싶지만 자동으로 처리해 주지 않으면(Organized Import 기능이 자동으로 처리해 주지만, 직접 명령을 수행해야 한다.) 역시 잊어버리기 쉽다.

이런 요구를 충족해 주는 기능으로 Save Actions 기능이 추가됐다. ‘Windows (윈도) /Eclipse (맥) -> Preferences -> Java -> Editor -> Save Actions’를 보면 저장 시 자동으로 문서 포맷 맞추기, 불필요한 Import 구문 정리하기 등의 기능을 제공한다. <화면 9>와 같이 저장 시 실행할 행동을 정의할 수 있으며, 문서 정렬은 전체 문서에 저장할 것인지 수정된 영역에만 적용할 것인지를 지정할 수 있다.

save.jpg

<화면 10 >저장 시 함께 처리할 행동 정의

 

Launch Configuration 내보내기/들여오기

Import(가져 오기)/Export(내보내기) 메뉴에 추가된 기능으로 그 동안의 실행 설정(Launch Configuration)을 XML 파일로 저장하고, 저장된 XML 파일을 가지고 오는 기능이 추가됐다.

이 설정은 JDK 버전을 여러 버전으로 맞춰놓고 작업하는 것(컴파일 레벨의 변경이 아니라 실제 JRE를 대체하면 전부 재빌드를 수행하므로 하나의 작업공간에서 모두 처리하기에는 번거롭다)과 같은 이유 등으로 이클립스를 여러 개 설치해 놓고 작업 하거나 작업 공간을 다시 구축해야 하는 경우 매번 복잡한 실행 설정을 하지 않아도 되기에 유용하다.

 

그 외 자바 개발 환경 개선사항

개발 중인 애플리케이션의 모든 메시지를 별도의 리소스 파일로 따로 뽑아서 관리한다면, 문자열 하나를 찾기 위해 키 값을 찾고, 리소스 파일을 열어서 다시 해당 키값으로 찾아가는 과정이 번거롭게 느껴진다. 가니메데에 새로 추가된 기능으로 리소스 파일로 바로 찾아가는 기능이 추가됐다.

이제 자바 빌드에서 멀티 코어 CPU를 지원한다. 기존의 프로젝트를 이클립스 3.4와 이전 버전의 이클립스에서 모두 새로 빌드해서 체감속도 향상을 느껴보자.

JUnit 테스트를 실행하면 이제 테스트케이스 별로 실행시간을 각각 표시해 준다. 오래 걸리는 테스트케이스를 따로 관리할 때 유용하다.

또, Content Assist 기능, Quick Fix 기능 등 에디터 영역이 전반적으로 편리해졌다.

 

자바 개발 환경외 주요 변경사항

여기서 다루는 내용은 이클립스 3.4의 자바 개발환경에서의 변경과 개선사항이지만, 자바 개발 환경 이외의 주요한 몇 가지 사항은 알아둘 가치가 있다. 물론 자바 개발과 관련 없는 가장 큰 변경 사항은 화려해진 시작 화면(스플래시 이미지)이다.

새로운 설치 /업데이트 서비스 – p2

기존에 업데이트 매니저를 이용해 플러그인을 설치하던 사용자라면 바로 알아차렸을 텐데, 이클립스의 플러그인 설치/업데이트 기능이 단순히 UI만 변경된 것이 아니라 완전히 새로 변경되었다.

다운로드 자동 재시도, 적합한 미러 자동 선택하기 등의 개선 사항이 있지만 무엇보다도, 기존 사용자들이 가장 불만을 가지고 있던 부분인 버전 의존성 확인 부분이 크게 개선되었다.

이클립스 소스 코드 보고 베끼기 - 플러그인 스파이

이클립스 3.4의 플러그인 개발 환경(Plug-in Development Environment, PDE) 에서 가장 눈에 띄는 기능은 ‘플러그인 스파이 (Plug-in Spy)’다. 이클립스를 사용하다 보면 플러그인 개발 자가 아닐지라도 , 어떻게 구현됐는지 코드 를 보고 싶은 경우가 있다. 기존에는 플러그인 개발자에게도 특정 영역의 코드를 찾아가는 작업이 쉽지 않았다. 이제 플러그인 스파이 덕분에 코드를 보고 싶은 관심 대상 화면을 선택한 후 ‘SHIFT +ALT+F1’을클릭하면 해당 화면이 정의된 플러그인과 해당 화면의 클래스 등 각종 정보를 쉽게 얻을 수 있다.

플러그인 스파이 기능을 활용하려면 PDE 관련 플러그인을 설치하거나 플러그인 개발자용 이클립스를 다운받아야 한다. 이클립스의 소스 코드를 참조해서 자신만의 플러그인을 만드는 내용에 대해서는 다음에 기회가 되면 자세히 알아보겠다.

자바스크립트 개발 툴킷

웹 개발 환경에서 가장 눈에 띄는 변화는 WTP 3.0에 새로 추가된 자바스크립트 개발 툴킷(JavaScript Development Toolkit, JSDT)이다. js 파일의 포맷팅 기능, 콜 계층 보기 지원 등의 기능이 눈에 띈다. 게다가 추가적인 자바스크립트 라이브러리의 지원을 위한 확장점도 제공하고 있으니, 자신만의 라이브러리를 지원하는 것도 용이하다. WTP 3.0에 포함된 기능이므로 WTP 3.0을 별도로 설치하거나 Java EE 버전 이클립스를 다운받으면 된다.

서브버전(SVN) 클라이언트 전쟁의 승자 –Subversive

가니메데에 서브버전 클라이언트로 Subversive 프로젝트가 채택되었다. 이미 그 전부터 예견된 일이었지만, 이로써 Subclipse보다 한 발 앞서 나가게 되었다.아직 서브버전 클라이언트를 결정하지 못했다면 Subversive를 도입해 보자. 승자라고 표현했지만, 정식 프로젝트로 합류가 빨랐을 뿐이지 아직 Subclipse가 사장되는 것은 아니 라는 점을 염두에 두자.

 

마치며

지금까지 이클립스 3.4 가니메데의 새로운 기능을 자바 개발자의 시각에서 알아보았다. 이클립스 는 새로운 버전이 나올 때 마다 하위 프로젝트의 규모가 계속 커지고 있 기에 새로운 기능을 모두 다루는 것은 현실적으로 불가능하다. 개인적으로는 여기서 소개한 내용 외에도 ECF 2.0 에 추가된 협업시스템을 이용한 인스턴스 메신저 와 짝 프로그래밍 지원 , DLTK프로젝트의 동적 언어 지원, 그리고 DSDP 프로젝트의 터미널 환경 지원 등 에 관심이 간다. 이처럼 자바 개발 환경 외에 새로운 기능 중에서도 자신에게 맞는 보석 같은 기능 들이 많이 숨겨져 있으니 간단히 한 번 살펴보는 것을 권한다 .

아직도 이클립스를 무거운 텍스트 에디터의 용도로 사용하 는 경우가 많은데, 시간을 조금만 투자하면 정말 훌륭한 IDE 로 활용할 수 있다. 필요한 기능부터 하나씩 적용해 나가보자 .

 

참고문헌

  1. 한눈에 보는 이클립스 가니메데
    http://www.ibm.com/developerworks/kr/library/os-eclipse-ganymede/index.html?ca=drs-kr

  2. Eclipse 3.4 – New and Noteworthy
    http://ganymede-mirror2.eclipse.org/eclipse/downloads/drops/R-3.4-200806172000/whatsnew3.4/eclipse-news.html

  3. Eclipse Ganymede: An in-depth look at JDT (Java Development Tools)

    http://www.infoq.com/news/2008/06/eclipse-ganymede-jdt

 

관련글

반응형
FTP? 자바?

FTP는 요즘 같은 인터넷 세상에서 빠지지 않는 프로토콜이다. FTP가 무엇인지 잘 모른다면 다음을 참고하자.
FTP (File Transfer Protocol) ; 파일 전송 프로토콜

FTP[에프 티 피]는 인터넷상의 컴퓨터들간에 파일을 교환하기 위한 표준 프로토콜로서 가장 간단한 방법이기도 하다. 화면에 표시할 수 있는 웹 페이지와 관련 파일들을 전송하는 HTTP (Hypertext Transfer Protocol), 전자우편을 전송하는 SMTP (Simple Mail Transfer Protocol)등과 같이, FTP도 역시 인터넷의 TCP/IP 응용 프로토콜 중의 하나이다. FTP는 웹 페이지 파일들을 인터넷상에서 모든 사람이 볼 수 있도록 하기 위해 저작자의 컴퓨터로부터 서버로 옮기는 과정에서 사용된다. 또한, 다른 서버들로부터 자신의 컴퓨터로 프로그램이나 파일들을 다운로드 하는 데에도 많이 사용된다.

사용자 입장에서는 간단한 명령어를 통하여 FTP를 쓰거나, 또는 그래픽 사용자 인터페이스를 제공하는 상용 프로그램을 쓸 수도 있다. 보통은 웹 브라우저도 웹 페이지로부터 선택한 프로그램을 다운로드 하는데 FTP를 사용한다. FTP를 사용하여 서버에 있는 파일을 지우거나 이름을 바꾸거나 옮기거나 복사하는 등 갱신작업을 할 수도 있다. FTP 서버에는 로그온을 해야 하지만, 익명의 FTP를 사용하여 모든 사람들에게 공개된 파일들을 쉽게 접근할 수 있도록 하고 있다.

FTP는 보통 TCP/IP에 함께 딸려오는 일련의 프로그램 속에 포함되어 있다.
간단히 말해서 FTP는 파일 전송 프로토콜이다. 우리는 FTP라는 프로토콜을 알게 모르게 많이 사용하고 있다. 회사 동료들 사이에 문서를 주고 받거나, 친구들과 음악 파일, 동영상 등을 주고 받는데 항상 사용하고 있는 것이다. 일반 컴퓨터 사용자들은 프로토콜이니 그런 것에는 관심 없을 것이다. 내가 원하는 파일을 주고 받기만 하면 될 뿐이니까… 그래도 FTP를 사용하기 위해서는 기본 명령을 알아야 한다. 하지만 이런 기본 명령 조차도 귀찮을 다름이다.

FTP 클라이언트 프로그램을 사용하면 FTP 명령을 알지 못하는 사람들도 GUI 환경에서 쉽게 FTP 서버에 접속해서 원하는 파일들을 주고 받을 수 있다. 일반적으로 많이 사용되는 FTP 클라이언트 프로그램으로는 WS_FTP, CuteFTP, 알FTP 등이 있다. 그렇다면 과연 누가 이런 FTP 클라이언트 프로그램을 만드는가? 당연히 개발자의 몫이다. 그럼 또한 자바로는 가능한가. 당연히 자바로도 가능하다. 원래 자바라는 언어 자체가 네트워크 분야에서 강력한 힘을 발휘한다고 하지 않는가? 이제부터 우리는 자바로 FTP 클라이언트 프로그램을 개발해 볼 것이다. 물론 다른 상용 프로그램처럼 훌륭한 GUI를 지원하는 프로그램은 아니다. 콘솔에서 작동하는 “Hello FTP”를 개발할 것이다. “에이, GUI가 없다면 썰렁할텐데…” 물론 이렇게 생각하는 분들도 있을 것이다. 하지만 모든 프로그램은 항상 “Hello”로부터 시작되므로 무시해서는 안될 것이다. 화려한 GUI 개발은 여러분들이 직접 해보시길 바란다. 아마 쉽지 않은 작업이 분명할 듯…

무엇이 필요한가?

당연히 자바로 개발하기 위해서는 JDK가 있어야 한다. JDK를 구하고 설치하는 것은 다른 자바 기초 서적을 참고하기 바란다.

자바만으로도 FTP 관련 프로그램을 만들 수 는 있다. sun.net.ftp 패키지에 보면 FTP 클라이언트 구현을 위한 클래스들이 있다. 하지만 필자가 프로젝트를 하면서 이 패키지를 사용해 보았는데, 몇몇 기능이 원하는 기능을 지원하지 않는 것을 알게 되었다. 그리고 썬사의 문서를 참고하면 sun으로 시작되는 패키지는 사용하지 말라고 권하고 있다.

아… 그렇다면 어찌해야 한단 말인가?
FTP 프로토콜을 지원하는 모든 기능을 다 구현해야 한다는 말인가? 충분한 시간과 실력이 된다면 그것도 좋은 방법이다. 일단 실력은 둘째 치고라도 우리에게는 충분한 시간이 없다. 이럴 때 도움을 받을 수 있는 수 많은 오픈 소스들과 공짜 패키지 들이 있지 않은가? 비겁하고 치사하다고 생각할 필요는 없다고 생각하자. 어차피 우리는 생활에 필요한 대부분의 것을 남이 만든 것을 사다 쓰고 있는 현실이니…

http://www.savarese.org/java/index.html에 가면 NetComponents에 대한 설명이 있다. 자세한 것은 읽어보면 알겠지만 소스 코드까지 무료로 사용할 수 있다. 우리는 이것을 사용할 것이다. http://www.savarese.org/downloads/NetComponents/에서 다운로드 받으면 된다. 필자는 NetComponents-1.3.8-bin.zip 파일을 다운로드 받아서 압축을 풀었다. 여러 폴더와 파일들이 있다. 필자는 윈도우를 사용하고 있다. 혹시 다른 운영체제를 사용한다면 문서들을 살펴보길 바란다.

NetComponents.jar 파일을 클래스패스에 추가하자. 클래스패스에 추가하는 방법을 모르는 분들은 다른 자바 기초 서적을 참고하시길… Doc 폴더에는 API 도움말이 있고 examples 폴더에는 여러 예제가 있다. 눈치 빠른 개발자들이라면 예제 파일을 본 후에 NetComponents가 아주 많은 프로토콜을 지원한다는 것을 쉽게 예상 할 수 있을 것이다. 공짜로 사용하는 것 치고는 아주 많은 기능을 제공한다. 여유가 되는 분들은 다른 기능도 사용해보고 이에 대한 기사 올려준다면 다른 개발자들에게 큰 힘이 될 것이 분명하다. 물론 예제에는 FTP도 포함되어 있으며(ftp.java) 본 기사에서도 이 예제를 참고할 것이다.

어떤 기능을 개발할 것인가?

프로그램을 개발하기 위해서는 어떤 것을 개발할 것인지, 어떤 기능을 수행해야 하는지를 명확히 알아야 한다. 이런 것들을 소프트웨어 공학에서는 “요구 사항” 이라고 한다. 요구 사항이 명확히 정의 되지 않으면 개발 도중에 많은 실수를 반복하고 기간이 늘어나기 쉽상이지만 우리가 개발할 프로그램의 요구 사항은 아래와 같이 간단하다.
  • FTP 서버에 접속한다.
  • 정해진 디렉토리로 이동한다.
  • 디렉토리 내의 사이즈가 0보다 큰 모든 로그 파일들을 가져온다.
혹시 다른 기능이 더 필요하다면 API 도움말을 참고하면 된다. 적절한 클래스와 메소드들을 사용해서 상용 FTP 클라이언트 프로그램들이 제공하는 기능은 대부부분 구현이 가능하다.

소스코드

코드 자체는 그리 어려운 부분이 없으므로 따로 설명이 필요할 것이 없다. 기능 자체가 워낙 간단해서인가? 여러분들은 그저 중간에 간단히 적힌 주석 부분만 참고하면 될 것이다. 컴파일을 하고 실행을 하면 화면에서는 나타나는 것이 없지만 실제로 파일이 전송된다. 여러분도 적절히 수정을 하여 원하는 파일들을 서버로부터 전송 받을 수 있을 것이다.
import java.io.*;

import com.oroinc.net.ftp.*;
import com.oroinc.net.*;

public class MyFtpClient {
    static String server = "xxxxx";
    static int port = 21;
    static String id = "xxxxx";
    static String password = "xxxxx";
    FTPClient ftpClient;

    public MyFtpClient(String server, int port, String id, String password) {
        this.server = server;
        this.port = port;
        ftpClient = new FTPClient();
    }

    public static void main(String args[]) {
        MyFtpClient ftp = new MyFtpClient(server, port, id, password);
        ftp.connect();
        ftp.login(ftp.id, ftp.password);
        // 로그파일이 있는 디렉토리로 이동한다
        ftp.cd("/home/ems/emsprj/project/wos/WosLog/log");
        FTPFile[] files = ftp.list();
        for (int i = 0; i < files.length ; i++) {
            String fileName = files[i].getName();
            // 파일 이름에서 확장자만 추출
            String extension = fileName.substring(fileName.lastIndexOf(".") + 1);
            long size = files[i].getSize();
            // 파일 사이즈가 0보다 크고 로그 파일만 가져온다
            if ( (size > 0) && (extension.equalsIgnoreCase("log")) ) {
                File file = ftp.get(fileName, fileName);
            }
        }
        ftp.logout();
        ftp.disconnect();
        System.exit(1);
    }

    // 계정과 패스워드로 로그인
    public boolean login(String user, String password) {
        try {
            this.connect();
            return ftpClient.login(user, password);
        }
        catch (IOException ioe) {
            ioe.printStackTrace();
        }
        return false;
    }

    // 서버로부터 로그아웃
    private boolean logout() {
        try {
            return ftpClient.logout();
        }
        catch (IOException ioe) {
            ioe.printStackTrace();
        }
        return false;
    }

    // 서버로 연결
    public void connect() {
        try {
            ftpClient.connect(server, port);
            int reply;
            // 연결 시도후, 성공했는지 응답 코드 확인
            reply = ftpClient.getReplyCode();
            if(!FTPReply.isPositiveCompletion(reply)) {
                ftpClient.disconnect();
                System.err.println("서버로부터 연결을 거부당했습니다");
                System.exit(1);
            }
        }
        catch (IOException ioe) {
            if(ftpClient.isConnected()) {
                try {
                    ftpClient.disconnect();
                } catch(IOException f) {
                    //
                }
            }
            System.err.println("서버에 연결할 수 없습니다");
            System.exit(1);
        }
    }

    // FTP의 ls 명령, 모든 파일 리스트를 가져온다
    public FTPFile[] list() {
        FTPFile[] files = null;
        try {
            files = this.ftpClient.listFiles();
            return files;
        }
        catch (IOException ioe) {
            ioe.printStackTrace();
        }
        return null;
    }

    // 파일을 전송 받는다
    public File get(String source, String target) {
        OutputStream output = null;
        try {
            File local = new File(source);
            output = new FileOutputStream(local);
        }
        catch (FileNotFoundException fnfe) {
            fnfe.printStackTrace();
        }
        File file = new File(source);
        try {
            if (ftpClient.retrieveFile(source, output)) {
                return file;
            }
        }
        catch (IOException ioe) {
            ioe.printStackTrace();
        }
        return null;
    }

    // 서버 디렉토리 이동
    public void cd(String path) {
        try {
            ftpClient.changeWorkingDirectory(path);
        }
        catch (IOException ioe) {
            ioe.printStackTrace();
        }
    }

    // 서버로부터 연결을 닫는다
    private void disconnect() {
        try {
            ftpClient.disconnect();
        }
        catch (IOException ioe) {
            ioe.printStackTrace();
        }
    }

}
참고문헌


반응형

반응형

▶ 클래스 설계 요령 ◀

 

1. 데이터는 항상 private로 한다.

    이것은 매우 중요하다. 다른 식으로 하면 캡슐화가 깨지고 만다. 가끔 접근자나 변경자 메소드를 추가로 만들어야 하지만, 그래도 인스턴스 필드를 private로 만드는 것보다 훨씬 낫다. 데이터가 설명되는 방법이 변할 수도 있지만 사용되는 방법은 잘 변하지 않는다. 데이터가 private이면 그러한 설명의 변화는 클래스의 사용자에 영향을 미치지 않으며, 버그를 발견하기도 훨씬 쉽다.

 

2.항상 데이터를 초기화한다.

    자바는 지역 변수를 초기화 하지 않지만, 객체의 인스턴스 필드는 자동으로 초기화 한다. 하지만 이런 기본 값에 의존하지 말고 기본값을 제공하거나 모든 생성자에 기본값을 설정하는 방법으로 변수를 명시적으로 초기화해준다.

 

3. 클래스에 너무 많은 기본타입을 사용하지 말아야 한다.

    많은 기본타입의 관련된 사용을 다른 클래스로 바꾸자는 발상은 클래스를 더 이해하기 쉽고, 변경하기 쉽게 해준다. 예를 들어, Customer 클래스의 인스턴스 필드를 Address 라는 클래스로 바꾸자.

   private String street;

   private String city;

   private String state;

   private int zip;

 

 이렇게 하면, 주소가 국제 주소 쳬계로 바뀐다 해도 쉽게 이변화에 대처할수 있다.

 

4. 모든필드에 개별적인 접근자와 변경자가 필요한것은 아니다.

    사원의 급여를 가져오고 설정할 필요가있다. 물론 일단 객체가 생성되면 채용일은 변경할 필요가 없다.

 

5. 클래스 정의를 위해 표준형태를 사용한다.

    항상 다음과 같은 순서로 클래스의 내용을 나열한다.

        public 특성

        패키지 범위 특성

        private 특성

    각 영역은 다음과 같이 나열한다.

        인스턴스 메소드

        정적 메소드

        인스턴스 필드

        정적 필드

 

    선의 자바 프로그래밍 언어의 코딩 스타일 가이드는 필드를 먼저 나열하고 그 다음에 메소드를 나열하도록 권장한다. 어떤 스타일을 사용하든지 가장 중요한 것은 일관성을 유지하는 것이다.

 

6. 클래스를 아주 많은 역할로 나눈다.

     물론 "아주 많은"이라는 말은 모호하다. 하지만 하나의 복잡한 클래스를 개념적으로 더 간단한 클래스 두 개로 만들 수 있다면 그 방법을 사용해야 한다 (단 극단적으로 가면 안된다. 가각 한 메소드만 포함하는 클래스 10개는 지나치다는 것이다)

다음 예는 잘못 설계된 클래스이다

 

     public class CardDeck{   //잘못된 설계

           private int[] value;

           private int[] suit;

 

           public CardDeck(){....}

           public void shuffle(){......}

           public int getTopValue(){......}

           public int getTopSuit(){.....}

           public void draw(){......}

     }

 

     이 클래스는 두개의 분리된 개념을 구현하고 있다.. 하나는 shuffle과 draw메소드를 갖는 한벌의 카드(deck of cards)이며, 다른 하나는 card로 값과 카드의 패를 검사하는 메소드를 가지고 있다. 이것은 각각의 카드를 표현하는 Card 클래스를 도입하는 것은 의미가 있다. 이제 독자적인 임무를 갖는 두 클래스를 살펴보자

 

      public class CardDeck{

           private Card[] cards;

 

           public CardDeck(){...}

           public void shuffle(){.....}

           public Card getTop(){......}

           public void draw(){.......}

      }

 

      public class Card{

           private int value;

           private int suit;

 

           public Card(int aValue,itn aSuit){...}

           public int getValue(){.....}

           public int getSuit(){......}

     }

 

7. 클래스와 메소드의 이름은 그 임무에 맞게 부여한다.

    변수는 그것이  표현하는 것을 나타내는 의미 있는 이름을 가져야 하듯이 클래스도 마찬가지이다 (표준 라이브러리는 시간을 서술하는 Date 클래스처럼 약간 미심쩍은 클래스를 포함하고있다).Order  같은 명사를 사용하거나, RushOrder 처럼 선행 형용사를 수바한 명사 또는 Billing-Address 와 같은 동명사로 클래스 이름을 부여하는 것은 좋은 규칙이다. 메소드에 대한 표준 규칙은 접근자 메소드는 getSalary 처럼 소문자 get으로 시작하고, 변경자 메소드는 setSalary처럼 소문자 set으로 시작하는 것이다.

반응형
사람의 욕심은 끝이 없구나...

언제나 자신의 욕심은 번뇌를 만들지만..

버리지 못하고 움켜쥔손은 펴질줄 모르는구나..

어미의 손을 놓칠까 두려운 아이처럼..

다시 맞잡은 두손을 꼬옥 부여잡고도

다시 그 손을 놓칠세라 잠이 들면서도 놓질 못하네

나를 중독시킨 내안의 고독

손을 내밀어 나의 손을 잡아 내안의 슬픈 고독과

그안에 움튼 외로움을 바람에 흘려....

비어버린 가슴 속 언저리를 채워..
반응형

형식 변환 함수

       

아래의 각 함수는 을 특정한 데이터 형식으로 변환합니다.

구문

CBool(expression)

CByte(expression)

CCur(expression)

CDate(expression)

CDbl(expression)

CDec(expression)

CInt(expression)

CLng(expression)

CSng(expression)

CVar(expression)

CStr(expression)

필수 항목인 expression 인수로는 모든 문자식이나 수식을 사용할 수 있습니다.

반환값

함수 이름에 따른 반환값의 형식은 아래와 같습니다

함수 반환 형식 expression 인수의 범위
Cbool Boolean 적절한 문자식이나 수식
Cbyte Byte 0 - 255
Ccur Currency -922,337,203,685,477.5808 - 922,337,203,685,477.5807
Cdate Date 유효한 모든 날짜식
CDbl Double 음수값인 경우: -1.79769313486232E308 -
-4.94065645841247E-324. 양수값인 경우: 4.94065645841247E-324 - 1.79769313486232E308
Cdec Decimal 소수점 이하 단위가 없는 경우: +/-79,228,162,514,264,337,593,543,950,335 소수점 이하 28자릿수의 값으로서 그 범위는
+/-7.9228162514264337593543950335. 가장 작은 표현 가능한 숫자는 0.0000000000000000000000000001
Cint Integer -32,768 - 32,767. 나머지는 반올림
CLng Long -2,147,483,648 - 2,147,483,647. 나머지는 반올림
CSng Single 음수값인 경우: -3.402823E38 - -1.401298E-45. 양수값인 경우: 1.401298E-45 - 3.402823E38
CStr String CStr에 대한 반환expression 인수에 따라 달라집니다.
Cvar Variant 숫자인 경우: Double과 같은 범위. 숫자가 아닌 경우: String과 같은 범위

출처 - MSDN


반응형

이클립스를 사용하다가 자주 버벅대는 경우와 뻗어버리는 경우가 생겼다.
heapsize를 체크해보니 64M 로 되어있는데 금방 차버리는 것이다.
분명 eclipse.ini 에 설정을 늘려놓았음에도 제대로 적용이 되지 않는것 같다.

이를 해결하는 방법
Eclipse.exe 아이콘의 오른쪽 버튼을 누른 후
[보내기] - [바탕화면에 바로가기 만들기] 로 생성한다
바탕화면에 생성된 Eclipse바로가기 아이콘에서 오른쪽 마우스를 누른 후
[속성]에서 대상 항목에 뒤에 다음과 같이 붙여 넣어주자

...\eclipse.exe -vmargs -XX:MaxPermSize=128m - Xms256m -Xmx512m

-Xms: Start memory
-Xmx: Extends memory

+ Recent posts