블로그 이미지
010-9967-0955 보미아빠

카테고리

보미아빠, 석이 (500)
밥벌이 (16)
싸이클 (1)
일상 (1)
Total
Today
Yesterday

달력

« » 2024.4
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30

공지사항

최근에 올라온 글

SQL Server 에서 지원하는 방법은 다음과 같은 Merge 구문이 가능하다.
그 외 join update 에 대해서도 간단하게 설명한다.

테이블 생성 - not null 컬럼을 테스트 하기 위해 원 아티클에서 컬럼 하나를 더 추가함

--Create a target table

drop table Products
drop table UpdatedProducts
go

CREATE TABLE Products
(
ProductID INT PRIMARY KEY,
ProductName VARCHAR(100),
Rate MONEY,
notnullcol int not null
)
GO
--Insert records into target table
INSERT INTO Products
VALUES
(1, 'Tea', 10.00,1),
(2, 'Coffee', 20.00,1),
(3, 'Muffin', 30.00,1),
(4, 'Biscuit', 40.00,1)
GO
--Create source table
CREATE TABLE UpdatedProducts
(
ProductID INT PRIMARY KEY,
ProductName VARCHAR(100),
Rate MONEY
)
GO
--Insert records into source table
INSERT INTO UpdatedProducts
VALUES
(1, 'Tea', 10.00),
(2, 'Coffee', 25.00),
(3, 'Muffin', 35.00),
(5, 'Pizza', 60.00)
GO
SELECT * FROM Products
SELECT * FROM UpdatedProducts
GO

Merge 구문 에서 not null 컬럼을 처리하기 위한 방법

MERGE Products AS TARGET
--USING UpdatedProducts AS SOURCE
USING
(select 1 ProductID, 'Tea' ProductName, 10.00 Rate union all
select 2 , 'Tea' , 10.00  union all
select 3 , 'Tea' , 10.00  union all
select 5 , 'Tea' , 10.00 ) AS SOURCE
ON (TARGET.ProductID = SOURCE.ProductID)
--When records are matched, update
--the records if there is any change
WHEN MATCHED AND TARGET.ProductName <> SOURCE.ProductName
OR TARGET.Rate <> SOURCE.Rate THEN
UPDATE SET TARGET.ProductName = SOURCE.ProductName,
TARGET.Rate = SOURCE.Rate
--When no records are matched, insert
--the incoming records from source
--table to target table
WHEN NOT MATCHED BY TARGET THEN
INSERT (ProductID, ProductName, Rate,notnullcol )
VALUES (SOURCE.ProductID, SOURCE.ProductName, SOURCE.Rate, 0)
--When there is a row that exists in target table and
--same record does not exist in source table
--then delete this record from target table
WHEN NOT MATCHED BY SOURCE THEN
DELETE
--$action specifies a column of type nvarchar(10)
--in the OUTPUT clause that returns one of three
--values for each row: 'INSERT', 'UPDATE', or 'DELETE',
--according to the action that was performed on that row
OUTPUT $action,
DELETED.ProductID AS TargetProductID,
DELETED.ProductName AS TargetProductName,
DELETED.Rate AS TargetRate,
INSERTED.ProductID AS SourceProductID,
INSERTED.ProductName AS SourceProductName,
INSERTED.Rate AS SourceRate;
SELECT @@ROWCOUNT;
GO

SELECT * FROM Products
SELECT * FROM UpdatedProducts


INSERT ... ON DUPLICATE KEY UPDATE Syntax 는 MSSQL 에서 위와 같이 바꿀 수 있다.
아래는 join update 의 설명이다.

sql server 에서는 오래전부터 update from 절을 제공해 오고 있고, 이것은 같은행을 무작위 update 할 수 있으며, merge 구문은 그런 현상이 발생하면 에러가 발생하게 되어 좀 더 안정적이다. udpate from 절은 ansi-sql 에서 없는 구문이며, sql server 만 지원하고 있다.

sql server 의 update from 예

UPDATE c
     SET Street = m.Street,

           HouseNo = m.HouseNo,

           City = m.City

  FROM Customers AS c

 INNER JOIN Moved AS m

     ON m.SSN = c.SSN;

mysql 의 경우 다음과 같은 구문을 제공한다.

UPDATE (
 SELECT site_code, company_code, description
   FROM site_info
  WHERE site_code > 2645
    AND site_code NOT IN (2721,2720,2719,2718,2717,2716)
  ORDER BY site_code DESC
 ) a
  JOIN site_threshold_set b
    ON a.site_code = b.site_code
   AND a.company_code = b.company_code
  JOIN (
 SELECT *
   FROM site_threshold_set
  WHERE site_code = 2710
 ) c
    ON b.alarm_code = c.alarm_code
   SET b.critical = c.critical
     , b.warning = c.warning
     , b.notice = c.notice

oracle 의 경우 subquery 와 merge 를 이용한 join update 가 가능하다.

Posted by 보미아빠
, |

MAC 주소를 바꾸어야 한다면 다음과 같이 하면 된다.
아래 그림의 값 중에서 앞 6자리는 제조사 정보이고 뒤 6자리는 MAC 주소이다.
해당값을 16진수로 적어 주면 된다.

그리고 해당 네트웍 카드를 사용안함 -> 사용 으로 한번만 클릭해주면 새로운 MAC 주소를 사용하게 된다.
햐~ 좋은거~


Posted by 보미아빠
, |


정규화 법칙은 업데이트 이상과 데이터 비일관성을 막기위해 디자인 되었다. 성능 Tradeoff 에 대해서, 이 가이드는 Non-key 속성은 자주 업데이트 된다고 가정한다. 이런 가정은 데이터 추출에는 비 효율적이다. 왜냐하면, 정규화되지 않은 경우 하나의 레코드에서 추출 될 수 있고, 정규화 폼에서는 아마도 여러 레코드에서 추출해 와야 할 수 있기 때문이다. 실제 성능 요구사항을 고려 할 때 모든 레코드를 완전히 정규화 할 의무는 없다.

 

삽입시 의도하지 않은 값들도 함께 삽입

삭제시 의도하지 않은 값들도 함께 삭제 (값 자체가 없어져 버린다.)

갱신시 전체 갱신되지 않고 일부만 갱신되는 것



1 정규화
1 정규형은 레코드 타입의 모양을 다룬다.
1 정규화는 하나의 레코드는 반드시 같은 필드 숫자로 이루어져야 한다.
1 정규화는 반복되는 필드와 그룹을 없애는 것이다. 정의의 문제지 디자인 가이드라인이 아니다. 관계형 데이터베이스 이론은 레코드들이 가변 필드를 갖는 것을 다루지 않는다.
참고) 하나의 필드에 여러값을 갖는 경우도 1정규화 위반 이라고 하지만, 이것은 데이터베이스 이론의 위반이다. (도메인 원자값)

2 정규화
non-key 필드 팩트가 전체 key 중 일부 key 의 팩터 일 때 발생한다. 이것은 여러 필드의 조합과 같이 key 가 복합키 일때만 일어난다. (부분적 함수 종속 제거)

3 정규화
non-key 필드가 다른 non-key 필드의 팩트일 때 발생한다. (이행적 함수 종속 제거)

BCNF (BoyceCodd Normal Form)
모든 결정자가 후보키 (결정자 이면서 후보키가 아닌것 제거)

 



4 정규화
서로 독립인 다중치 속성일 경우 발생한다. (다치 종속 제거)

 



5 정규화 (PJNF, Project-Join Normal Form)
서로 독립이 아닌 다중치 속성일 경우 발생한다. (조인 종속성 제거)

 

 


6 정규화 (DKNF, Domain-Key Normal Form)
계좌의 Account 가 9로 시작하고, 잔고가 2500불 이상이면 다른 테이블에 들어간다.

 

 


http://blog.naver.com/jinsol1/100024608148


아주 심플하게 정리 했다. 그 이상의 정규형이 있으면 좀 알려주세요~ ^.^ 이것보다 더 쉽게 설명 할 수는 없을듯...
이거 강의하고 조광원 아저씨처럼 쉽게 설명한다는 이야기를 들어 매우 기분이 좋았습니다.





A Simple Guide to Five Normal Forms in Relational Database Theory 에 자세히 설명되어 있으며 매우 쉽게 예제와 함께 설명한다.

위 내용을 다 이해한다면, 3정규화 까지만 해라는 말을 못 할 듯 하다.


이번 정규화 발표가 데이터베이스 디자인시 도움이 되었으면 합니다.
수고하세요~

첨부파일은 원본 입니다.

A Simple Guide to Five Normal Forms in Relational Database .pdf

 

한글자료 
          http://yuhani.springnote.com/pages/917834

어드벤스드 자료로 5정규화와 6정규화의 내용은 다음을 참고한다.

정규화 adx.ppt

 

정규화 adx 한글판.ppt

 









William Kent, "A Simple Guide to Five Normal Forms in Relational Database Theory", Communications of the ACM 26(2), Feb. 1983, 120-125. Also IBM Technical Report TR03.159, Aug. 1981. Also presented at SHARE 62, March 1984, Anaheim, California. Also in A.R. Hurson, L.L. Miller and S.H. Pakzad, Parallel Architectures for Database Systems, IEEE Computer Society Press, 1989. [12 pp]

A Simple Guide to Five Normal Forms in Relational Database Theory
관계형데이터베이스 이론에서의 5정규화의 간단한 가이드

1 소개 **************
관계형 데이터베이스 이론에서 정규화란 레코드 디자인에 대한 가이드라인이다. 본 가이드라인은 1정규화 부터 5정규화 까지를 다룬다. 용어는 관계이론의 이해 없이 볼 수 있는 것들이다. 이 디자인 가이드라인들은 관계형 데이터베이스를 사용하지 않더라도 충분히 의미 있는 것이다. 일반화를 강조하기 위해, 관계형 모델의 컨셉의 참조 없이 가이드라인을 제시한다. 더불어 좀 더 이해하기 쉽게 하기 위해서이다. 이 프리젠테이션은 레코드 디자인의 의도된 제약을 직관적으로 전달한다. 약식(비공식적)이지만 몇몇 기술적 세부사항은 부정확 할 수 있다. 이 주제를 포괄적으로 다루는 것은 Date [4] 에서 다룬다.

정규화 법칙은 업데이트 이상과 데이터 비일관성을 막기위해 디자인 되었다. 성능 Tradeoff 에 대해서, 이 가이드는 Non-key 속성은 자주 업데이트 된다는 가정한다. 이런 가정은 데이터 추출에는 비 효율적이다. 왜냐하면, 정규화되지 않은 경우 하나의 레코드에서 추출 될 수 있고, 정규화 폼에서는 아마도 여러 레코드에서 추출해 와야 할 수 있기 때문이다. 실제 성능 요구사항을 고려 할 때 모든 레코드를 완전히 정규화 할 의무는 없다.

2. Frist Normal Form **************
E.F. Codd, "A Relational Model of Data for Large Shared Data Banks", Comm. ACM 13 (6), June 1970, pp. 377-387.
The original paper introducing the relational data model.

1 정규형은 레코드 타입의 모양을 다룬다.
1 정규화는 하나의 레코드는 반드시 같은 필드 숫자로 이루어져야 한다.
1 정규화는 반복되는 필드와 그룹을 없애는 것이다. 정의의 문제지 디자인 가이드라인 이 아니다. 관계형 데이터베이스 이론은 레코드들이 가변 필드를 갖는 것을 다루지 않는다.

1정규화 위반사례 1 (데이터베이스 이론의 정의 위반)
아이디, 취미1, 취미2, 취미3
민석, 싸이클, 영화감상, SQL Server
만철, 오락실게임, SQL Server Bulk Operation,null
산아, SQL Server, null, null

1정규화 위반사례 2 (반복 그룹 - 업데이트 어떻게 할꺼야?)
아이디, 취미
민석, 싸이클
민석, 영화감상
민석, SQL Server
만철, 오락실 게임
만철, SQL Server Bulk Operation
산아, SQL Server
참고) 하나의 필드에 여러값을 갖는 경우도 1정규화 위반 이라고 하지만, 이것은 데이터베이스 이론의 위반이다.

3. SECOND AND THIRD NORMAL FORMS **************
E.F. Codd, "Normalized Data Base Structure: A Brief Tutorial", ACM SIGFIDET Workshop on Data Description, Access, and Control, Nov. 11-12, 1971, San Diego, California, E.F. Codd and A.L. Dean (eds.).
An early tutorial on the relational model and normalization.

E.F. Codd, "Further Normalization of the Data Base Relational Model", R. Rustin (ed.), Data Base Systems (Courant Computer Science Symposia 6), Prentice-Hall, 1972. Also IBM Research Report RJ909.

W. Kent, "A Primer of Normal Forms", IBM Technical Report TR02.600, Dec. 1973.
An early, formal tutorial on first, second, and third normal forms.

2 정규화와 3정규화는 관계에서 non-key 와 key 필드를 다룬다.
2 정규화와 3정규화 에서는 하나의 non-key 필드는 key 에 대해서 반드시 하나의 팩트를 제공해야 한다. 복합키의 경우도 전체 키에 하나의 팩터를 제공해야 한다. 그리고, 이 레코드들은 1 정규화를 준수해야 한다.

이제부터 단지 하나의 값만을 가지는 팩트를 다룰 것이다. 팩트는 부서와 사원과 같이, one-to-many 관계를 가질것이다. 또는, 사원과 배우자와 같이 one-to-one 관계이다. "X 는 Y 의 팩터이다." 라는 것은 X 와 Y 에 대해 one-to-one 이나 one-to-many 관계이다.
Y 는 하나 이상의 컬럼을 가지고, X 는 그렇지 않을 것이다. 수량은 파트와 창고 조합의 팩트이다.

3.1 Second Normal Form
2 정규화 위반은 non-key 필트 팩트가 전체 key 중 일부 key 의 팩터일때 발생한다. 이것은 여러 필드의 조합과 같이 key 가 복합키 일때만 일어난다. 아래와 같은 인벤토리 레코드를 생각해 보자.

---------------------------------------------------
| PART | WAREHOUSE | QUANTITY | WAREHOUSE-ADDRESS |
====================-------------------------------

key 는 part 와 warehouse 두개의 조합으로 이루어져 있다. 하지만 warehouse-address 는 warehose 하나에만 속하는 팩터이다. 이러한 디자인의 기본적인 문제는 다음과 같다.

* warehose 에 있는 part별 warehouse address 는 모든 행에서 반복된다.
* 만약 warehose-address가 갱신되면,그 warehouse 에 있는 모든 part 의 warehouse-address 가 업데이트 되어야 한다.
* 중복으로 들어가 있기 때문에 데이터 일관성을 잃을 수 도 있다. 같은 warehose 에 다른 warehouse-address 가 보여질 수 있다.
* 만약 어떤 시간에서 warehose 에 part 가 없으면, warehouse-address 를 유지 할 수 없다.

2 정규화의 문제에서 안전하기 위해서는 위 예제의 레코드는 두개의 레코드로 분리 되어야 한다.

-------------------------------  ---------------------------------
| PART | WAREHOUSE | QUANTITY |  | WAREHOUSE | WAREHOUSE-ADDRESS |
====================-----------  =============--------------------

데이터 디자인이 이런 방법으로 변화되면 정규화 되지 않은 레코드들은 정규화된 레코드로 된다. 이러한 프로세스를 정규화라 한다. 정규화(normalization)의 용어는 때때로 특정 정규 폼에 상대적으로 사용된다. 그래서, 하나의 레코드셋이 2 정규화에 대해서는 정규 폼을 지키고 3 정규형에 대해서는 아닐 수 있다.

중복과 비일관성을 최소화 함으로 정규화된 디자인은 데이터 완전성을 향상시킨다. 하지만 특정 검색 어플리케이션의 성능 비용이 더 야기되기도 한다. 어떤 어플리케이션이 warehose 에 있는 part 의 warehouse-address 를 보려고 할 때, 비 정규화된 폼에서는 하나의 레코드만 보면되나, 정규화된 디자인에서는 그 어플리케이션은 2개의 레코드 타입을 조사한 후 적절한 패어로 연결해야 한다.

3.2 Third Normal Form
3 정규화 위반은 non-key 필드가 다른 non-key 필드의 팩트일 때 발생한다.

------------------------------------
| EMPLOYEE | DEPARTMENT | LOCATION |
============------------------------

employee 필드는 키 필드이다. 만약 각 department 가 한 곳에 있다면, location 필드는 department 의 팩트이다. 더해서 employee 도 팩트가 된다. 이러한 디자인의 문제는 아래와 같이 2 정규화 위반과 같다.

* department 에 할당된 모든 employee 에 department의 location 이 중복되어 나타난다.
* 만약 department 의 location 이 변경되면, 이러한 모든 레코드가 업데이트 되어야 한다.
* 중복 때문에 데이터는 일관정을 잃을 수 있고, 같은 department 에 대해 다른 location 을 보일 수 있다.
* 만약 department 에 employee 가 없으면, department 의 location 정보를 보존 할 수 없다.

요약하면, 모든 필드는 키의 부분이나 하나의 팩트를 전달 할때 전체키에 연관되어야 한다. 다른건 없다. 이렇때 레코드는 2,3 정규화의 폼이다.

3.3 Functional Dependencies
데이터베이스 이론에서, 2,3 정규화 폼은 함수 종속으로 정의된다. 우리의 싱글 밸류 팩트에 일치한다. 어떤 필드 Y 는 X 필드(들)에 "함수 종속" 이며 만약 두개의 레코드가 있을 때 같은 X 가 다른 Y 값을 가지면 이것은 종속이 아니다. 다르게 말하면, 주어진 X 값은 항상 같은 Y 값을 가진다. X 가 key 이면, 모든 필드들은 정의에 의해 X 에 종속된다. 그렇기 때문에 같은 X 값에 대해 2개의 레코드를 가질 수 없다.

여기 함수 종속과 우리가 보여준 단일값 팩트는 기술적으로 약간 틀린점이 있다. 함수 종속은 유니크 와 단일 식별자에서만 존재한다. 예를 들자면 어떤 사람의 주소가 단일값 팩트 일때를 가정해 보자. 그 사람은 하나의 주소만 가지고 있다. 만약 우리가 사람에 대해 unique 식별자를 제공하지 못하면, 함수 종속되지 못한다.

(동명 2인)
------------------------------------------
|   PERSON   |       ADDRESS                 |
-------------+--------------------------------
| John Smith | 123 Main St., New York        |
| John Smith | 321 Center St., San Francisco |
----------------------------------------------

사람이 단일 주소를 가지지만, 주어진 이름이 여러 다른 주소를 나타낼 수 있다. 그렇기 때문에 우리의 단일값 팩트는 함수 종속에 해당하지 않는다.

마찬가지로, address는 함수 종속성을 만족하기 위해 동일한 철자를 써야 한다. 다음과 같은 경우는 같은 사람이 두개의 다른 주소를 가지는 것 처럼 보인다. 다시 말해 함수 종속성을 불가능 하게 한다.

(같은 사람이며, 주소를 다르게 표시함)
---------------------------------------
|   PERSON   |       ADDRESS          |
-------------+-------------------------
| John Smith | 123 Main St., New York |
| John Smith | 123 Main Street, NYC   |
---------------------------------------

유니크하지 않거나 비 단일 식별자를 사용하면 보호하지 못한다. 이런 예제는 종종 데이터 관리 문제를 유발 시킨다.  지적 하고자 하는것은, 기능적 종속과 다양한 정규화들은 유니크나 단일 식별자가 있을때만 정의된다. 그래서, 디자인 가이드라인은 정규화 공식 정의에 적용된 것 보다 좀 더 암시적이다.

예를 들어, 디자이너는 다음 예제에서 어떤 non-key 필드가 단일값 팩터 임을 안다. 이 디자인은 위에서 언급한 모든 업데이트 이상에 해당된다.   

----------------------------------------------------------
| EMPLOYEE  |  FATHER    |  FATHER'S-ADDRESS             |
|============------------+-------------------------------|
| Art Smith | John Smith | 123 Main St., New York        |
| Bob Smith | John Smith | 123 Main Street, NYC          |
| Cal Smith | John Smith | 321 Center St., San Francisco |
----------------------------------------------------------

하지만, 공식 용어에서, father's-address 와 father 사이에는 함수 종속이 없다. 그러므로, 3정규화 위반이 아니다.


1nf 하나의 컬럼에 한개의 값만 있을것

2nf 키 컬럼에 종속되는 컬럼은 테이블 분리 

3nf 키가 아닌 컬럼에 종속되는 컬럼은 테이블 분리

bcnf 일반컬럼이 복합키 컬럼 일부에 종속되는 경우 테이블 분리

4nf 복합키가 다른 주제영역을 다루고 있을경우 1:n 으로 분리한다. 

5nf 4nf 에서 주제 영역간 n:m 관계가 있을때 각각을 1:n 으로 분리해 join 종속성을 제거한다. 

1~3까지만 실무에 쓰임 

Posted by 보미아빠
, |

요즘 넘 운동을 안해서 함 달렸다. 오랜만에~~~~슉 슉~ 왜 저렇게 수줍어 하지...ㅡ.ㅡ 이상하네....
여자 사람이 밤 라이딩 나와서 그런가......ㅋㅋㅋㅋㅋ

Posted by 보미아빠
, |

 

봄양 사랑해~ 뿡~뿡~

 

Posted by 보미아빠
, |

안녕하세요 김민석 입니다.

이번 SQLTAG 2차 Online Study 에서는 SQL Server 의 Parallel 에 대한 이해 입니다.

먼저 http://blogs.msdn.com/b/craigfr/archive/2007/04/17/parallel-query-execution-presentation.aspx 에서 소개된 ppt 를 죽 설명하면서 parallel 의 이해를 해 보았습니다. Craig Freedman 은 SQL Server Query Team 에 있는 Optimizer 개발자 입니다. SQL Server 뿐만 아니라 다른 상용 데이터베이스의 Optimizer 에 대해서도 개발한 전력이 있어 보였습니다.

1. Scalability Terminology 를 먼저 이해야해 하고 SQL Server Parallel 은 공짜가 아니라는 점을 설명 합니다.
2. SQL Server 가 기본적으로 Parallel 하게 풀기 위해서는 affinity mask, max degree of parallelism, cost threshold for parallelism, max worker threads 의 올바른 설정이 필요 합니다.  
3. CPU Utilization 에서는 SQL Server 2000 과 2005의 차이점을 설명 합니다.
4. Parallelism Operator 에서 producer 와 consumer 의 개념을 설명 합니다.
5. Gather Stream Repartition Streams, Distribute Streams 의 개념을 설명 합니다.
6. Routing 기법중 Broadcast, Hash, Round Robin, Demand, Range 를 설명 합니다.
7. Order preserving Non-order preserving 혹은 merging non-merging exchange 를 설명 합니다.
8. Parallel Scan 에 대해 설명 합니다.
9. Query Plan 예제를 설명 합니다.
10. Non-Parallelizable "Stuff" 에 대해 설명 합니다.
    UDF, CLR, Object_id, Error_number, @@trancount, Dynamic Cursors, System table scans, Sequence Functions, Top, Backward Scan, Recursive queries, TVSs, Global scalar aggregate, Multi-cumsumer spool

위 개념을 이해하면 Parallel 에 대한 기본적인 것을 알 수 있습니다. merge (Order preserving) 이 일어나는 Gather Stream 이나 Merge Join 이 일어날 때 Parallel Thread 가 높은 CPU 사용량을 쓰는 CPU 에 할당되게 되면 그 속도가 대단히 느려지는 이유를 정확하게 이해 할 수 있습니다. 기본적으로 대단히 높은 CPU 사용율을 보이는 프로세서에 thread 가 같이 할당되면 처리해야하는 데이터베이스 page 숫자만큼 os 에 자신이 처리될 수 있도록 요청하는 현상이 일어나게 되고 그 주기는 select os_quantum from sys.dm_os_sys_info 에 기술된 ms 만큼 소요 됩니다. 그러므로, 어떤 한 코어가 100% 사용율을 보일때 maxdop 옵션을 줄여 튜닝하게 되면, 때때로 운 없이 바쁜 core 에 Thread 가 할당되어 쿼리 응답시간을 예측가능하게 디자인 할 수 없습니다. 우리가 튜닝할때 가장 중요하게 생각하는 것은 쿼리의 응답시간이 예측 가능해야 한다는 것입니다. 역시 sqlworkshops.com 의 R. Meyyappan 도 결론적으로 어떻게 튜닝해야 한다는 해법은 제공해 주지 않았습니다.

이러한 것을 풀 수 있는 방법은 언듯 생각하기에 3가지 정도 방법이 있을듯 합니다.

1. Resouce Governor ( http://msdn.microsoft.com/en-us/library/bb933866.aspx )를 이용
2. Soft Numa 와 TCP Port Mapping 기법
3. Merge join의 경우 Hash Join 으로 변경이 가능한지 쿼리를 non-order preserving 하게 만들수 있는지 여부 검사

Soft-Numa 와 TCP Port Mapping 기법 입니다.

1. Soft-Numa 의 이해 
   http://blogs.msdn.com/b/psssql/archive/2010/04/02/how-it-works-soft-numa-i-o-completion-thread-lazy-writer-workers-and-memory-nodes.aspx

2. Soft-numa Registery 설정
    http://msdn.microsoft.com/en-us/library/ms345357.aspx

3. Numa 와 TCP/IP 의 연결 
   http://msdn.microsoft.com/en-us/library/ms345346.aspx

간단한 스크린샷 입니다.



   



다양한 Test 를 하기위해 모든 경우의 수 생성
20001[1],20002[2],20003[3],20004[4],20005[5],20006[6],20008[8],20009[9],20010[10],20011[11],20012[12],20013[13],20014[14],20015[15]

역시 테스트 하시다 모르는게 있으면 언제든지 email, phone, www.sqltag.org qna 로 연락 주시면 아는데 까지 설명 드리겠습니다. 질문 하실때는 반드시 전화번호를 같이 남겨 주세요.

즐거운 SQL 시간 되세요.

Posted by 보미아빠
, |


과거에 한 60만원짜리 모니터인데 저렴하게 중고로 들여왔다.
나는 불안해서 안전거래 했는데, 불량나서 바꾸러 갔는데 새걸로 바구어 주셨다.
사무실 집기 땡기러 다니시는 분이란다. 혹시 저렴하게 하나 들이고 싶은분은 적극 추천 드려요.
그나저나 내책장 넘 잘생겨 졌다 흐흐~

010 6824 6002 로 전화하면 왼쪽 Dell 모니터 구할 수 있다.

Posted by 보미아빠
, |
SQLTAG.ORG 에서 발표한
Sort Warning 을 주제로 한 테스트 스크립트와 해결방법을 설명하기위한 데모 스크립트 입니다.

powered by http://sqlworkshops.com/ 

테스트 하시다가 막히거나 모른는 부분이 있으면 언제든지 질문 하세요.
실제 고급 sql 엔지니어도 모르는 경우가 많은 예제 입니다.




Posted by 보미아빠
, |


메모리 상황을 보기위해 현재 가장 편한것은 dbcc memorystatus 이다. 이것을 이용해 어떤 메모리 영역에 문제가 있을 수 있는지 한번에 알아볼 수 있는 좋은 방법을 소개한다.

DMV 는 Session 당 할당 메모리를 보거나 뭐 더 좋은 많은 결과를 볼 수 있는 쿼리가 존재 한다. 그러나 DMV 는 모든 정보를 제공하지 않고 오직 dbcc memorystatus 만 모든 정보를 제공한다.

 select granted_memory_kb, used_memory_kb, max_used_memory_kb
   from sys.dm_exec_query_memory_grants
  where session_id = 55


과거 버전의 서버에서 토탈 어떻게 사용하고 있는지 편리하게 제공하는 방법이 없다. 그래서 set nocount on 과 dbcc memorystatus 결과를 c:\dbcc.txt 라는 파일로 만들어 sql 로 파싱해서 편리하게 분석해 보자
눈으로 살펴보다가 내 눈이 심히 피곤했고, 이 결과를 파일로 만들어 넣은것은 헤더 정보를 같이 볼 방법은 이 방법밖에 없었다. 2005 이상에서는 편리하게 쿼리 할 수 있지만 2000 일 수 도 있어 쿼리를 과거 버전과 호환성 있게 만드느라 이렇게 만들었다.


동작 방법

xp_cmdshell 활성화가 필요하다.
강제로 설정하고 예전 설정으로 돌리면 되지만 작업 할려니 귀찮다.




모니터링 방법

use master
go
if object_id ('dbcc_memorystatus') is not null
drop proc dbcc_memorystatus
go

create proc dbcc_memorystatus
as
set nocount on
set transaction isolation level read uncommitted
-- script by minsouk kim
-- sqlsql.tistory.com
-- sqltag.org
-- 2011.08.30
-- xp_cmdshell 활성화 필요
declare @srvname varchar(1000)
   , @sql varchar(8000)
   , @ins_filename varchar(1000)
  
select @srvname = srvname from sysservers where srvid = 0
select @ins_filename = replace(@srvname,'\','_')
set @sql = 'sqlcmd -S '+@srvname+' -E -q "set nocount on; dbcc memorystatus;" -o c:\'+@ins_filename+'_dbcc_memorystatus.txt'
EXEC master..xp_cmdshell @sql ,no_output
if object_id ('tempdb..##dbcc_raw') is not null
drop table ##dbcc_raw
if object_id ('tempdb..##dbcc_memorystatus') is not null
drop table ##dbcc_memorystatus
if object_id ('tempdb..##dbcc_memorystatus_header') is not null
drop table ##dbcc_memorystatus_header
if object_id ('tempdb..##memorystatus') is not null
drop table ##memorystatus
create table ##dbcc_raw
(value varchar(1000))
set @sql = '
BULK INSERT ##dbcc_raw
FROM ''\\127.0.0.1\c$\'+@ins_filename+'_dbcc_memorystatus.txt''
WITH
(
TABLOCK
)'
exec (@sql)
create table ##dbcc_memorystatus
(idx int identity(1,1), value varchar(1000))
insert into ##dbcc_memorystatus
select * from ##dbcc_raw
create table ##dbcc_memorystatus_header
(idx int identity(1,1), header_idx int)
insert ##dbcc_memorystatus_header
select idx
  from ##dbcc_memorystatus
 where case when value like '%-%' then 1 else 0 end = 1
select * into ##memorystatus
from (
select h.description type, v.description, v.value, h.scale
  from (select b.header_idx - 1 header_idx, b.header_idx+1 st_idx, a.header_idx-3 ed_idx
    from ##dbcc_memorystatus_header a
    join ##dbcc_memorystatus_header b
   on a.idx = b.idx + 1) d
  join (select idx
    , substring(value,1, len(value) - charindex(' ',reverse(rtrim(value)))) description
    , substring(value,len(value) - charindex(' ',reverse(rtrim(value)))+1,100) scale
    from ##dbcc_memorystatus ) h
    on d.header_idx = h.idx
  join (select idx
    , substring(value,1, len(value) - charindex(' ',reverse(rtrim(value)))) description
    , substring(value,len(value) - charindex(' ',reverse(rtrim(value)))+1,100) value
    from ##dbcc_memorystatus ) v
    on v.idx between d.st_idx and ed_idx
 -- where h.description+v.description like '%sqlcp%'   
 --order by cast(v.value as bigint) desc
 ) a
PRINT 'select * from ##memorystatus where type+description like ''%sqlcp%'''
PRINT 'select * from ##memorystatus where type+description like ''%GLOBAL%'' ORDER BY CAST(VALUE AS BIGINT) DESC'
PRINT 'select * from ##memorystatus order by cast(value as bigint) desc '
-- select * from ##memorystatus
go

exec dbcc_memorystatus 



결과 예제 


SQL Server 2000 DBCC MEMORYSTATUS 에 대한 기술 정보
http://support.microsoft.com/?id=271624
SQL Server 2005 DBCC MEMORYSTATUS 에 대한 기술 정보
http://support.microsoft.com/?id=907877 



 

Posted by 보미아빠
, |


나는 이것을 프로시저와 메모리 그랜트 이슈라고 부르기 보다. "쿼리를 여러개로 분리하면 좋은 경우다" 라고 말하고 싶다.
실제 많은 이와 같은 프로시저는 경우에 따라 여러 sub procedure 를 콜 하도록 구성한다. steatement level recompile 도 용서 할 수 없는 경우가 있기 때문이다. 

이 문서에는 recompile 하는 것이 좋겠다고 하지만, 우리는 이런경우 여러개로 분리해 쓴다.
아래 이유가 잘 설명되어 있지만. 쿼리플랜이 만들어질때 메모리 할당량이 설정되기 때문에 sort warning 이 생길수 있다는 관점에서 recompile 을 해 적당한 메모리를 할당 받으라는 것이다. 

그러나, 실제 운영을 해보면, 이런 이슈보다 기간에 따라 쿼리 플랜이 달라져야 하고 인덱스를 다르게 써야 하는경우가 더 많았다. 그걸 수용하기 위해서는 statement level 의 recompile 이나, 분리된 다른 sub procedure 를 힌트로 박아 운영하는 것이 더 보편적인 이슈 해결 방법 이였다.

다음 사이트를 참고해서 학습하면 좋을듯 하다.
http://www.sqlworkshops.com/plancachingandquerymemory.htm

참고로 이분이 소개한 대부분의 내용이 옵티마이저를 소개한 블로그에서 먼저 소개되어 있다. 하지만, 현실적으로 어떻게 이러한 문제를 해결하는게 좋을지에 대한 해답은 여기가 가장 좋은듯 하다. 

배껴서 강의하면 재미 날듯 해 한국어로 완벽하게 이해하는 강의를 해봐야지....SQLTAG 에서도 TeamView + 게임톡 강의로 많은 사람들과 이런 이슈를 하나 하나 나누어 보아야겠다. 언어의 장벽을 SQL에는 없도록 해봐야지.

비슷한 주제로 김정선 강사님이 강의 했다는데 들어 두었으면 좋았을걸..하는 아쉬움이 남는다. 아쉽게 스터디 날짜랑 같아 모두 한배타고 아무도 못 들었다. -_- 제가 책임지고 같은 주제로 더 심도깊게 강의 해 드리겠습니다. 운영의 경험 + 수많은 KB 조사까지 넣어 (알지 ?).

모두들 즐거운 SQL Time 되세요~

이번것은 넘 쉬어서 변역 안할란다.




Let’s create a stored procedure that sorts customers by name within certain date range.

To observe Sort Warnings, enable 'Sort Warnings' in SQL Profiler under Events 'Errors and Warnings'.

--Example provided by www.sqlworkshops.com

create proc CustomersByCreationDate @CreationDateFrom datetime, @CreationDateTo datetime as

begin

      declare @CustomerID int, @CustomerName varchar(48), @CreationDate datetime

      select @CustomerName = c.CustomerName, @CreationDate = c.CreationDate from Customers c

            where c.CreationDate between @CreationDateFrom and @CreationDateTo

            order by c.CustomerName

      option (maxdop 1)

      end

go

Let’s execute the stored procedure initially with 1 month date range.

set statistics time on

go

--Example provided by www.sqlworkshops.com

exec CustomersByCreationDate '2001-01-01', '2001-01-31'

go

The stored procedure took 48 ms to complete.

 

The stored procedure was granted 6656 KB based on 43199.9 rows being estimated.

 

The estimated number of rows, 43199.9 is similar to actual number of rows 43200 and hence the memory estimation should be ok.

 

There was no Sort Warnings in SQL Profiler. To observe Sort Warnings, enable 'Sort Warnings' in SQL Profiler under Events 'Errors and Warnings'.

 

Now let’s execute the stored procedure with 6 month date range.

--Example provided by www.sqlworkshops.com

exec CustomersByCreationDate '2001-01-01', '2001-06-30'

go

The stored procedure took 679 ms to complete.

 

The stored procedure was granted 6656 KB based on 43199.9 rows being estimated.

 

The estimated number of rows, 43199.9 is way different from the actual number of rows 259200 because the estimation is based on the first set of parameter value supplied to the stored procedure which is 1 month in our case. This underestimation will lead to sort spill over tempdb, resulting in poor performance.

 

There was Sort Warnings in SQL Profiler. To observe Sort Warnings, enable 'Sort Warnings' in SQL Profiler under Events 'Errors and Warnings'.

 

To monitor the amount of data written and read from tempdb, one can execute select num_of_bytes_written, num_of_bytes_read from sys.dm_io_virtual_file_stats(2, NULL) before and after the stored procedure execution, for additional information refer to the webcast: www.sqlworkshops.com/webcasts.

 

Let’s recompile the stored procedure and then let’s first execute the stored procedure with 6 month date range.

In a production instance it is not advisable to use sp_recompile instead one should use DBCC FREEPROCCACHE (plan_handle). This is due to locking issues involved with sp_recompile, refer to our webcasts for further details.

exec sp_recompile CustomersByCreationDate

go

--Example provided by www.sqlworkshops.com

exec CustomersByCreationDate '2001-01-01', '2001-06-30'

go

Now the stored procedure took only 294 ms instead of 679 ms.

 

The stored procedure was granted 26832 KB of memory.

 

The estimated number of rows, 259200 is similar to actual number of rows of 259200. Better performance of this stored procedure is due to better estimation of memory and avoiding sort spill over tempdb.

 

There was no Sort Warnings in SQL Profiler.

 

Now let’s execute the stored procedure with 1 month date range.

--Example provided by www.sqlworkshops.com

exec CustomersByCreationDate '2001-01-01', '2001-01-31'

go

The stored procedure took 49 ms to complete, similar to our very first stored procedure execution.

 

This stored procedure was granted more memory (26832 KB) than necessary memory (6656 KB) based on 6 months of data estimation (259200 rows) instead of 1 month of data estimation (43199.9 rows). This is because the estimation is based on the first set of parameter value supplied to the stored procedure which is 6 months in this case. This overestimation did not affect performance, but it might affect performance of other concurrent queries requiring memory and hence overestimation is not recommended. This overestimation might affect performance Hash Match operations, refer to article Plan Caching and Query Memory Part II for further details.

 

Let’s recompile the stored procedure and then let’s first execute the stored procedure with 2 day date range.

exec sp_recompile CustomersByCreationDate

go

--Example provided by www.sqlworkshops.com

exec CustomersByCreationDate '2001-01-01', '2001-01-02'

go

The stored procedure took 1 ms.

 

The stored procedure was granted 1024 KB based on 1440 rows being estimated.

 

There was no Sort Warnings in SQL Profiler.

 

Now let’s execute the stored procedure with 6 month date range.

--Example provided by www.sqlworkshops.com

exec CustomersByCreationDate '2001-01-01', '2001-06-30'

go

The stored procedure took 955 ms to complete, way higher than 679 ms or 294ms we noticed before.

 

The stored procedure was granted 1024 KB based on 1440 rows being estimated. But we noticed in the past this stored procedure with 6 month date range needed 26832 KB of memory to execute optimally without spill over tempdb. This is clear underestimation of memory and the reason for the very poor performance.

 

There was Sort Warnings in SQL Profiler. Unlike before this was a Multiple pass sort instead of Single pass sort. This occurs when granted memory is too low.

 

Intermediate Summary: This issue can be avoided by not caching the plan for memory allocating queries. Other possibility is to use recompile hint or optimize for hint to allocate memory for predefined date range.

Let’s recreate the stored procedure with recompile hint.

--Example provided by www.sqlworkshops.com

drop proc CustomersByCreationDate

go

create proc CustomersByCreationDate @CreationDateFrom datetime, @CreationDateTo datetime as

begin

      declare @CustomerID int, @CustomerName varchar(48), @CreationDate datetime

      select @CustomerName = c.CustomerName, @CreationDate = c.CreationDate from Customers c

            where c.CreationDate between @CreationDateFrom and @CreationDateTo

            order by c.CustomerName

      option (maxdop 1, recompile)

      end

go

Let’s execute the stored procedure initially with 1 month date range and then with 6 month date range.

--Example provided by www.sqlworkshops.com

exec CustomersByCreationDate '2001-01-01', '2001-01-30'

exec CustomersByCreationDate '2001-01-01', '2001-06-30'

go

The stored procedure took 48ms and 291 ms in line with previous optimal execution times.

 

The stored procedure with 1 month date range has good estimation like before.

 

The stored procedure with 6 month date range also has good estimation and memory grant like before because the query was recompiled with current set of parameter values.

 

The compilation time and compilation CPU of 1 ms is not expensive in this case compared to the performance benefit.

 

Let’s recreate the stored procedure with optimize for hint of 6 month date range.

--Example provided by www.sqlworkshops.com

drop proc CustomersByCreationDate

go

create proc CustomersByCreationDate @CreationDateFrom datetime, @CreationDateTo datetime as

begin

      declare @CustomerID int, @CustomerName varchar(48), @CreationDate datetime

      select @CustomerName = c.CustomerName, @CreationDate = c.CreationDate from Customers c

            where c.CreationDate between @CreationDateFrom and @CreationDateTo

            order by c.CustomerName

      option (maxdop 1, optimize for (@CreationDateFrom = '2001-01-01', @CreationDateTo ='2001-06-30'))

      end

go

Let’s execute the stored procedure initially with 1 month date range and then with 6 month date range.

--Example provided by www.sqlworkshops.com

exec CustomersByCreationDate '2001-01-01', '2001-01-30'

exec CustomersByCreationDate '2001-01-01', '2001-06-30'

go

The stored procedure took 48ms and 291 ms in line with previous optimal execution times.

 

The stored procedure with 1 month date range has overestimation of rows and memory. This is because we provided hint to optimize for 6 months of data.

 

The stored procedure with 6 month date range has good estimation and memory grant because we provided hint to optimize for 6 months of data.

 

Let’s execute the stored procedure with 12 month date range using the currently cashed plan for 6 month date range.

--Example provided by www.sqlworkshops.com

exec CustomersByCreationDate '2001-01-01', '2001-12-31'

go

The stored procedure took 1138 ms to complete.

 

2592000 rows were estimated based on optimize for hint value for 6 month date range. Actual number of rows is 524160 due to 12 month date range.

 

The stored procedure was granted enough memory to sort 6 month date range and not 12 month date range, so there will be spill over tempdb.

 

There was Sort Warnings in SQL Profiler.

 

As we see above, optimize for hint cannot guarantee enough memory and optimal performance compared to recompile hint.

This article covers underestimation / overestimation of memory for Sort. Plan Caching and Query Memory Part II covers underestimation / overestimation for Hash Match operation. It is important to note that underestimation of memory for Sort and Hash Match operations lead to spill over tempdb and hence negatively impact performance. Overestimation of memory affects the memory needs of other concurrently executing queries. In addition, it is important to note, with Hash Match operations, overestimation of memory can actually lead to poor performance.

Summary: Cached plan might lead to underestimation or overestimation of memory because the memory is estimated based on first set of execution parameters. It is recommended not to cache the plan if the amount of memory required to execute the stored procedure has a wide range of possibilities. One can mitigate this by using recompile hint, but that will lead to compilation overhead. However, in most cases it might be ok to pay for compilation rather than spilling sort over tempdb which could be very expensive compared to compilation cost. The other possibility is to use optimize for hint, but in case one sorts more data than hinted by optimize for hint, this will still lead to spill. On the other side there is also the possibility of overestimation leading to unnecessary memory issues for other concurrently executing queries. In case of Hash Match operations, this overestimation of memory might lead to poor performance. When the values used in optimize for hint are archived from the database, the estimation will be wrong leading to worst performance, so one has to exercise caution before using optimize for hint, recompile hint is better in this case.

Posted by 보미아빠
, |

최근에 달린 댓글

최근에 받은 트랙백

글 보관함