리터럴(Literal) SQL이란? SQL문장 작성시 WHERE절의 비교되는 값에 문자/숫자 상수값을 하드코딩해서 작성한 것을 말하며, Bind Variable SQL이란 WHERE절의 특정값을 표시하는 자리에 바인드 변수 형태(:B)로 표시한 것을 말한다.
리터럴 SQL문을 많이 사용하면 하드파싱의 빈도를 높이게 되어 Library Cache 내에서 Cache되는 SQL문들이 자주 age out 하게 되므로 주기를 빠르게 하고 Dictionary Cache의 사용률을 높이게 된다. 이러한 Shared SQL Area의 SQL문 중에서 리터럴 SQL 문들을 찾아서 Bind Variable을 이용한 방법으로 바꾸어야 성능향상에 도움이 된다.
하나의 SELECT문의 결과가 다른 Select문의 결과와 합집합, 교집합, 차집합 등 새로운 결과를 만들어 낼 때 사용하는 연산자 이다. 이러한 집한 연산자를 사용하기 위해서는 연산을 하는 SELECT문의 결과와 칼럼 구조(개수, 타입)가 같아야 한다. 즉 같은 데이터 형이며 순서 또한 같아야 한다. 결과의 칼럼 명은 첫번째 SELECT문의 칼럼 명이 사용된다.
UNION : 연결된 Select문의 결과 합을 구해준다. 중복된 것은 하나만 보여줌
UNION ALL : 연결된 Select문의 결과 합을 구해준다.
중복된 ROW가 있더라도 모두 보여줌, 정렬이 일어나지 않는다.
INTERSECT : 연결된 Select문의 결과 교집합을 구해준다.
MINUS : 연결된 Select문의 결과 차를 구해준다.
-- 먼저 EMP에 테이블에 생성되어 있는 인덱스 및 칼럼을 확인하자.
SQL> SELECT a.index_name, a.column_name, b.visibility
FROM user_ind_columns a, user_indexes b
WHERE a.table_name = 'EMP'
AND a.index_name = b.index_name ;
-- 인덱스가 없다면 CREATE INDEX로 생성, 이미 있다면 SKIP
SQL> CREATE INDEX idx_emp_job ON EMP(job);
SQL> CREATE INDEX idx_emp_deptno ON EMP(deptno);
-- 먼저 EMP에 테이블에 생성되어 있는 인덱스 및 칼럼을 확인하자.
SQL> SELECT a.index_name, a.column_name, b.visibility
FROM user_ind_columns a, user_indexes b
WHERE a.table_name = 'EMP'
AND a.index_name = b.index_name ;
-- 인덱스가 없다면 생성, 있으면 SKIP
SQL> CREATE INDEX idx_emp_job ON EMP(job);
SQL> CREATE INDEX idx_emp_deptno ON EMP(deptno);
CHOOSE 힌트는 테이블에 통계 정보가 존재한다면 CBO(COST BASED OPTIMIZER)의 ALL_ROWS로 동작을 하고 통계정보가 없다면 RBO(RULE-BASED OPTIMIZER)로 동작한다. CBO의 ALL_ROWS는 비용 기반 옵티마이저 환경에서 SQL문의 WHERE 조건을 만족하는 모든 행을 가장 빠르게 검색하는 실행 계획을 유도하며 RBO인 경우 15개 규칙에 기반한 실행계획을 수립한다. (ORACLE 11g 이후 더 이상 지원하지 않지만 여전히 사용은 가능하다.)
리터럴(Literal) SQL이란? SQL문장 작성시 WHERE절의 비교되는 값에 문자/숫자 상수값을 하드코딩해서 작성한 것을 말하며, Bind Variable SQL이란 WHERE절의 특정값을 표시하는 자리에 바인드 변수 형태(:B)로 표시한 것을 말한다.
리터럴 SQL문을 많이 사용하면 하드파싱의 빈도를 높이게 되어 Library Cache 내에서 Cache되는 SQL문들이 자주 age out 하게 되므로 주기를 빠르게 하고 Dictionary Cache의 사용률을 높이게 된다. 이러한 Shared SQL Area의 SQL문 중에서 리터럴 SQL 문들을 찾아서 Bind Variable을 이용한 방법으로 바꾸어야 성능향상에 도움이 된다.
하나의 SELECT문의 결과가 다른 Select문의 결과와 합집합, 교집합, 차집합 등 새로운 결과를 만들어 낼 때 사용하는 연산자 이다. 이러한 집한 연산자를 사용하기 위해서는 연산을 하는 SELECT문의 결과와 칼럼 구조(개수, 타입)가 같아야 한다. 즉 같은 데이터 형이며 순서 또한 같아야 한다. 결과의 칼럼 명은 첫번째 SELECT문의 칼럼 명이 사용된다.
UNION : 연결된 Select문의 결과 합을 구해준다. 중복된 것은 하나만 보여줌
UNION ALL : 연결된 Select문의 결과 합을 구해준다.
중복된 ROW가 있더라도 모두 보여줌, 정렬이 일어나지 않는다.
INTERSECT : 연결된 Select문의 결과 교집합을 구해준다.
MINUS : 연결된 Select문의 결과 차를 구해준다.
-- 먼저 EMP에 테이블에 생성되어 있는 인덱스 및 칼럼을 확인하자.
SQL> SELECT a.index_name, a.column_name, b.visibility
FROM user_ind_columns a, user_indexes b
WHERE a.table_name = 'EMP'
AND a.index_name = b.index_name ;
-- 인덱스가 없다면 CREATE INDEX로 생성, 이미 있다면 SKIP
SQL> CREATE INDEX idx_emp_job ON EMP(job);
SQL> CREATE INDEX idx_emp_deptno ON EMP(deptno);
-- 먼저 EMP에 테이블에 생성되어 있는 인덱스 및 칼럼을 확인하자.
SQL> SELECT a.index_name, a.column_name, b.visibility
FROM user_ind_columns a, user_indexes b
WHERE a.table_name = 'EMP'
AND a.index_name = b.index_name ;
-- 인덱스가 없다면 생성, 있으면 SKIP
SQL> CREATE INDEX idx_emp_job ON EMP(job);
SQL> CREATE INDEX idx_emp_deptno ON EMP(deptno);
CHOOSE 힌트는 테이블에 통계 정보가 존재한다면 CBO(COST BASED OPTIMIZER)의 ALL_ROWS로 동작을 하고 통계정보가 없다면 RBO(RULE-BASED OPTIMIZER)로 동작한다. CBO의 ALL_ROWS는 비용 기반 옵티마이저 환경에서 SQL문의 WHERE 조건을 만족하는 모든 행을 가장 빠르게 검색하는 실행 계획을 유도하며 RBO인 경우 15개 규칙에 기반한 실행계획을 수립한다. (ORACLE 11g 이후 더 이상 지원하지 않지만 여전히 사용은 가능하다.)
[20140830, Pycon2014] NetworkX를 이용한 네트워크 분석Kyunghoon Kim
UNIST(유니스트)
NaturalScience Mathematical Sciences Kyunghoon Kim
자연과학부 수리과학과 김경훈
기본적인 네트워크 분석
Python Library NetworkX Tutorial Korean Version
http://www.pycon.kr/2014/program/7
Slideshare View 창에서는 슬라이드의 링크들이 모두 적용되지 않는 것 같습니다.
Save 하셔서 보시면 모든 링크들을 사용하실 수 있습니다.
OWASP Top 10 2013이 발표되었습니다. 이번 업데이트는 2010년 Top 10에 비해 일반적이면서도 중요한 취약점 분류
기준을 확대 적용하였으며, 얼마나 많이 퍼져있는가를 기준으로 순위를 재조정하였습니다. 또한 2010년 Top 10의
‘A6:보안 설정 오류’의 세부적인 설명의 모호함을 해소하고자, 위협 분류 가운데 컴포넌트 보안을 새로 포함하였습니다.
OWASP Top 10 2013은 애플리케이션 보안을 전문으로 하는 7개 기업의 8개 데이터세트를 토대로 하였습니다. 이
데이터들은 수백 개 기업, 수천 개의 애플리케이션에 걸친 500,000개 이상의 취약점들을 포함하고 있습니다. Top 10 각 항목들은 이 가운데 가장 많이 퍼져있는 데이터를 기준으로, 취약점 공격 가능성, 탐지 가능성, 그리고 영향 평가 등을 함께 고려하여 선정되었습니다.
OWASP Top 10을 선정하는 가장 큰 이유는 가장 중요한 웹 애플리케이션의 보안 취약점 개발자, 설계자, 아키텍트, 운영자, 혹은 기관들에게 주요 웹 애플리케이션 보안 취약점으로 인한 영향을 알리기 위해서입니다. Top 10은 위험도가 큰 문제들에 대해 대응할 수 있는 기본적인 기술을 제공하며, 또한 이를 근거로 향후 방향을 제시하고 있습니다.
[20140830, Pycon2014] NetworkX를 이용한 네트워크 분석Kyunghoon Kim
UNIST(유니스트)
NaturalScience Mathematical Sciences Kyunghoon Kim
자연과학부 수리과학과 김경훈
기본적인 네트워크 분석
Python Library NetworkX Tutorial Korean Version
http://www.pycon.kr/2014/program/7
Slideshare View 창에서는 슬라이드의 링크들이 모두 적용되지 않는 것 같습니다.
Save 하셔서 보시면 모든 링크들을 사용하실 수 있습니다.
OWASP Top 10 2013이 발표되었습니다. 이번 업데이트는 2010년 Top 10에 비해 일반적이면서도 중요한 취약점 분류
기준을 확대 적용하였으며, 얼마나 많이 퍼져있는가를 기준으로 순위를 재조정하였습니다. 또한 2010년 Top 10의
‘A6:보안 설정 오류’의 세부적인 설명의 모호함을 해소하고자, 위협 분류 가운데 컴포넌트 보안을 새로 포함하였습니다.
OWASP Top 10 2013은 애플리케이션 보안을 전문으로 하는 7개 기업의 8개 데이터세트를 토대로 하였습니다. 이
데이터들은 수백 개 기업, 수천 개의 애플리케이션에 걸친 500,000개 이상의 취약점들을 포함하고 있습니다. Top 10 각 항목들은 이 가운데 가장 많이 퍼져있는 데이터를 기준으로, 취약점 공격 가능성, 탐지 가능성, 그리고 영향 평가 등을 함께 고려하여 선정되었습니다.
OWASP Top 10을 선정하는 가장 큰 이유는 가장 중요한 웹 애플리케이션의 보안 취약점 개발자, 설계자, 아키텍트, 운영자, 혹은 기관들에게 주요 웹 애플리케이션 보안 취약점으로 인한 영향을 알리기 위해서입니다. Top 10은 위험도가 큰 문제들에 대해 대응할 수 있는 기본적인 기술을 제공하며, 또한 이를 근거로 향후 방향을 제시하고 있습니다.
탑크리에듀(http://www.topcredu.co.kr), 오라클자바커뮤니티(http://ojc.asia)에서 제공하는 온라인 무료 화상교육, 오라클 SQL힌트/튜닝 강의자료 3회차 입니다. 12월22일 진행되는 교육에서는 중첩루프조인 소개 및 USE_NL, USE_NL_WITH_INDEX, ORDERED 힌트 구문에 대해 살펴볼 예정 입니다.
행(ROW)들의 집합에 대해 연산을 하는 것이므로 행들의 집합 수 만큼 결과가 반환된다. 테이블은 GROUP BY절에 의해 그룹으로 나누어 질 수 있으며 그룹함수(Aggregation Function)는 SELECT문과 HAVING절에 사용 되어 질 수 있다. HAVING절은 GROUP BY 되는 함수에 조건을 주기 위해서 사용 되며 WHERE 절을 이용해서는 안 된다.(그룹핑 칼럼에 조건을 주는 경우는 WHERE절, HAVING절 모두에서 사용가능 하다.)
GROUP BY절을 이용하여 한 테이블에서 행들을 원하는 그룹으로 나누는 것이 가능하며 칼럼 명을 집합 함수와 SELECT절에 이용하고자 한다면 GROUP BY 뒤에 칼럼을 추가 해야 한다. 즉 SELECT절에 그룹함수가 오면 SELECT절의 나머지 칼럼은 GROUP BY절에 나타나야 한다. 또한 GROUP BY절에는 칼럼의 위치 순서 표기(1, 2, 3,,,)나 칼럼 Alias는 사용 할 수 없다.
탑크리에듀교육센터(topcredu.co.kr)에서 제공하는 자료입니다.
SQL초보에서 Schema Objects까지 25번째 자료입니다.
단일/복합(결합) 인덱스(Single Column/Composite Index),고유/비고유 인덱스(Unique/Non Unique Index), Descending Index, 함수기반 인덱스(Function Based Index), 인덱스 재구성 및 삭제, 인덱스 숨기기(Index Invisible)에 대하여 설명한 자료이오니 확인 후 많은 도움 되셨길 바랍니다^^.
세미 조인은 보통 EXISTS를 사용하는 서브쿼리의 형태로 나타나며 이러한 경우 서브 쿼리에 인덱스가 존재하지 않는다면 상당히 비효율적인데 SEMI-JOIN이 일어나도록 유도한다면 성능의 향상을 꽤 할 수 있다. 즉 인덱스 없이 EXISTS를 사용하는 쿼리라면 HASH_SJ or MERGE_SJ or NL_SJ 힌트를 이용해서 세미조인이 일어나도록 푸는 것이 좋다.
WHERE절에 인덱스 구성 컬럼이 ‘<’>’와 같이 범위 제한 연산자에 의해 이용되거나 BETWEEN or LIKE와 같은 조건 절에 이용될 때 INDEX RANGE SCAN을 하게 된다. 만약 결합(복합) 인덱스라면 범위 제한자에 사용되는 컬럼은 인덱스 구성 컬럼 중 선두 컬럼이여야 한다. 조건을 만족하는 첫 번째 레코드를 인덱스 블록에서 추출 후 조건에 맞는 데이터가 나올 때 까지 계속 스캔하는 나가는 방식으로 INDEX, INDEX_ASC 힌트를 사용할 때 나타나는 연산자이다.
아래 예에서 EMP TABLE에는 sal에 대해 오름차순 순방향 인덱스가 구성되어 있다.
(Index Range Scan이 가능하도록 하는 힌트는 INDEX_RS 이다.)
INDEX_DESC 힌트 구문을 사용했을 때 나타나는 실행계획 연산자로, 인덱스 영역에서 데이터를 역순으로 스캔하므로 데이터는 인덱스 생성 순서와는 반대로 정렬되어 있다.
인덱스 칼럼이 IN-LIST구에 나타나는 경우의 ROW 연산이며 INLIST ITERATOR는 IN-LIST의 인수 만큼 반복연산을 수행한다.
FILTER 연산은 데이터 추출 시 필터링이 일어나고 있음을 알려주는 SQL ROW 연산인데 WHERE 조건 절에서 인덱스를 사용하지 못할 때 발생한다. NESTED LOOP 방식으로 해석할 수 있는데 서브쿼리라면 메인쿼리 로우를 하나씩 읽을때 마다 서브쿼리를 한 번씩 실행하는 형태이다.
FILTER OPERATION은 IN, NOT IN, EXISTS, NOT EXISTS 를 사용하는 경우 발견할 수 있는 OPERATION이며 중첩 루프조인(Nedted Loop Join)과 유사하게 움직인다. 메인쿼리의 결과에 대해 서브쿼리의 결과값을 버퍼에 임시저장해 같거나 다른 것을 찾아 나가는 방식이다. 이러한 과정이 드라이빙되는 테이블의 각 로우에 대해 일어나기 때문에 NESTED LOOP JOIN과 유사하다고 볼 수있다.
ANTI 조인은 조인의 대상이 되는 테이블과 일치하지 않는 데이터를 추출하는 연산으로 SQL연산에서 NOT IN, NOT EXISTS, MINUS 등이 있을 때 나타나는 실행계획 연산자이다. 안티 조인은 NESTED LOOP ANTI-JOIN, MERGE ANTI-JOIN 또는 HASH ANTI_JOIN으로 풀리도록 할 수 있는데 대체로 HASH ANTI_JOIN이 성능상 좋다.
2. SCHEDULE
1. SQL GUIDE
① SQL작성시 유의사항 – SQL 활용가이드 참고
② JOIN
③ SUBQUERY
④ Optmizer의 이해
⑤ EXPLAIN
2. Query Tuning
① Clustring Index, Covering Index
② UNION, UNION ALL
③ ANY, EXISTS
3. Data Modeling
① 엔터티, 속성, 식별자, 관계
4. Logical Modeling
① 작도방법, 보는 방법
5. Physical Modeling
① 규칙 및 유의사항
3. STRUCTURED QUERY LANGUAGE, 구조화 질의어
Standard?
SQL-86 First published by ANSI. Ratified by ISO in 1987
SQL-89 Minor revision
SQL-92 or SQL2 - Major revision (ISO 9075) - MySQL start
SQL:1999 or SQL3
SQL:2003
SQL:2006
SQL:2008
SQL:2011 ISO/IEC 9075-1:2011 CHE 172
http://en.wikipedia.org/wiki/SQL
4. BEFORE WRITE QUERY…
어떻게 처리할 것인지를 먼저 생각하지 말고 무엇을 할 것인지를 먼저 파악하라.
그러한 결과 값을 얻기 위해 어떤 집합 이 필요한지를 찾아라.
필요한 집합이 논리적 으로 가능한지를 확인한다. 그러나 그 집합을 구체적으로 어떻게 생성할 것인지는 아직 생각하지
마라. 구체적인 생성 방법은 나중에 해도 충분하다.
원하는 집합이 생성 가능하다면 그 전체 집합을 마치 하나의 테이블로 간주 하라. 다시 말하면 원하는 집합을 테이
블에 넣었다고 생각하라. 그러면 지금부터는 하나의 테이블에 있는 정보를 가공 처리하는 단순한 형태가 된다.
추출되어야 할 결과 집합의 로우 단위 를 명확히 해라. 즉, 어떤 단위로 중분류를 해야 하는가(G roup by ) 를 결
정하라.
한 레코드씩 추출될 추출 단위( 중분류) 별로 내부에 속한 실제 로우들의 가공 처리 방법을 결정한다. 각각의 레코드마다 여
러 개의 실제 로우가 모여서 한 레코드가 되는 것이므로 여러 개의 실제 로우를 경우에 따라 어떤 방법으로 가공시키라는
것은 곧 SUM( x x x x ) 문 에 서 'x x x x '로 표시된 부분에 각 로우마다 해당되는 경우의 수를 처리 하는 것이다.
추출한 항목이 완성되었으 면 남겨 두었던 전체 집합을 구할 방법을 구체적으로 생각한다.
조인 이나 UNION 등을 활용하되 액세스 경로의 양호한 정도를 감안 한다.
SQ L을 수행시켜 가면서 약간의 보정을 통해 결론에 도달한다. 이때 수행 속도 에 대한 대비책도 같이 테스트 해야 한
다.
- 대용량 데이터베이스 솔루션 Ⅱ의 1장 89페이지 중에서
5. JOIN
MySQL JOIN Syntax
manual comment…
table_references: table_reference [, table_reference] ...
• table_factor 구문은 SQL 표준에 비해 확장 되었다.
table_reference: table_factor | join_table
• MySQL에서, CROSS JOIN 은 INNER JOIN과 동등하다. 표준 SQL에서
table_factor: 는 그렇지 않다. INNER JOIN은 ON 절과 함께 쓰이며 CROSS JOIN은
tbl_name [[AS] alias] [index_hint_list] 그렇지 않다.
| table_subquery [AS] alias
| ( table_references ) • STRAIGHT_JOIN 은 왼쪽 테이블이 오른쪽 테이블보다 항상 먼저 읽힌
| { OJ table_reference LEFT OUTER JOIN table_reference 다는 점을 제외하면 JOIN과 동일하다. JOIN optimizer가 테이블을 잘못
ON conditional_expr } 된 순서로 놓을 경우에 사용될 수 있다.
join_table: MySQL 5.0.12에서 변경된 JOIN연산
table_reference [INNER | CROSS] JOIN table_factor [join_condition]
| table_reference STRAIGHT_JOIN table_factor • NATURAL 이나 USING join의 컬럼들은 이전 버전과 다를 수 있다.
| table_reference STRAIGHT_JOIN table_factor ON conditional_expr • SQL:2003표준과 비교하여 MySQL에서의 확장은 MySQL이 NATURAL
| table_reference {LEFT|RIGHT} [OUTER] JOIN table_reference join_condition 이나USING join의 common 컬럼 들을 조절 할수 있게 하였는데 이는 표
| table_reference NATURAL [{LEFT|RIGHT} [OUTER]] JOIN table_factor 준 SQL문에서는 허용되지 않는다.
join_condition:
ON conditional_expr
| USING (column_list) + arkiz comment…
index_hint_list: • MySQL은 기본적으로 Nested Join을 수행한다.
index_hint [, index_hint] ... • FROM절의 테이블중 index가 없는 테이블이 구동테이블
• 둘 다 인덱스가 있는 경우 가장 왼쪽부터(표준은 오른쪽부터)
index_hint:
USE {INDEX|KEY} • Table Driving은 FROM절 가장 왼쪽 테이블부터 구동된다.
[FOR {JOIN|ORDER BY|GROUP BY}] ([index_list])
| IGNORE {INDEX|KEY} • STRAIGHT_JOIN, index hint 는 가급적 사용하지 않도록 하며, 필요 시
[FOR {JOIN|ORDER BY|GROUP BY}] (index_list) DB파트와 상의하여 사용한다.
| FORCE {INDEX|KEY}
[FOR {JOIN|ORDER BY|GROUP BY}] (index_list) • 외부조인시 LEFT, RIGHT JOIN 절 뒤에 오는 table 의 해당하는 컬럼이
WHERE절에서 언급되면 외부조인은 내부조인문으로 변경 될 수 있다.
index_list: index_name [, index_name] ...
6. SUBQUERY
subquery sample Scalar subquery
- SELECT List절에 한 개 column 값만을 반환
SELECT
(SELECT Inline view
column2 Scalar subquery
FROM table - FROM 절에 레코드 리스트를 반환
WHERE column1 = a.column1)
FROM (SELECT
columns Inline view Subquery
FROM table) AS a - SELECT statement에 포함하는 또 다른 SELECT
WHERE column1 > (SELECT value
FROM table subquery statement
WHERE column2 = 1)
AND column2 > (SELECT value
FROM table Correlated subquery Correlated subquery
WHERE column2 = a.column1) - FROM 절에 레코드 리스트를 반환
* 적용 기준(권장사항)
1. Select List Scalar Subquery를 수행할 결과집합이 대량이 아닌 경우
2. 코드성 테이블의 조인이 많아 실행계획이 복잡해져 제어가 어려운 경우
3. 코드성 테이블에서 명칭만 가져오는 경우 (단, 코드에서 명칭만 가져오더라도 결과 집합이 대량이면 스칼라 서브쿼리가 불리할
수 있으므로 대량인 경우 조인을 사용할 것)
4. 한 개의 테이블에서 복수 개의 컬럼을 가져오는 경우 스칼라 서브쿼리(두개의 컬럼을 ||로 묶어서 한 개의 컬럼을 리턴)를 사용
하지 말고 조인을 사용하도록 함