블로그 이미지
보미아빠

카테고리

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

달력

« » 2025.11
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

공지사항

최근에 올라온 글

3월 30일 팀뷰강좌 스크립트

 

IF OBJECT_ID ('TBLX') IS NOT NULL
DROP TABLE TBLX
GO

-- 1000 개의 다른값 넣기
SELECT TOP 1000 ROW_NUMBER() OVER (ORDER BY (SELECT 1)) IDX
 , CAST('A' AS CHAR(20)) COL1
 , CAST('A' AS CHAR(50)) COL2
INTO TBLX
FROM SYS.OBJECTS A1
, SYS.OBJECTS A2
, SYS.OBJECTS A3

-- 같은값 1000개 넣기
INSERT INTO TBLX (IDX, COL1, COL2)
SELECT 1, COL1, COL2 FROM TBLX

-- 인덱스 만들기
CREATE CLUSTERED INDEX CL_TBLX ON TBLX (COL1)
CREATE NONCLUSTERED INDEX NC_TBLX_01 ON TBLX (IDX)

-- 프로시저 만들기
IF OBJECT_ID ('PARATEST') IS NULL
EXEC ('CREATE PROC PARATEST AS SELECT 1')
GO

DBCC SHOW_STATISTICS (TBLX, NC_TBLX_01)
SELECT 2000 * 0.001

-- 일반적인 테스트 (파라메터 스니핑 함)
ALTER PROC PARATEST (@PARA INT)
AS
SELECT DISTINCT IDX, COL1, COL2
  FROM TBLX A
 WHERE IDX = @PARA
GO

EXEC DBO.PARATEST 1
DBCC FREEPROCCACHE
EXEC DBO.PARATEST 2

-- 스니핑을 방지하는 방법 1
ALTER PROC PARATEST (@PARA INT)
AS
DECLARE @PARA_V INT = @PARA
SELECT DISTINCT IDX, COL1, COL2
  FROM TBLX A
 WHERE IDX = @PARA_V
GO

-- 스니핑을 방지하는 방법 2
ALTER PROC PARATEST (@PARA INT)
AS
SELECT DISTINCT IDX, COL1, COL2
  FROM TBLX A
 WHERE IDX = @PARA
OPTION (OPTIMIZE FOR (@PARA UNKNOWN))
GO

-- 스니핑을 방지하는 방법 3
ALTER PROC PARATEST (@PARA INT)
AS
SELECT DISTINCT IDX, COL1, COL2
  FROM TBLX A
 WHERE IDX = @PARA%@PARA+@PARA
GO

EXEC DBO.PARATEST 1
DBCC FREEPROCCACHE
EXEC DBO.PARATEST 2

-- 그래도 꼭 읽고 싶습니다.
ALTER PROC PARATEST (@PARA INT)
AS
SELECT DISTINCT IDX, COL1, COL2
  FROM TBLX A
 WHERE IDX = @PARA%@PARA+@PARA
OPTION (RECOMPILE)
GO

EXEC DBO.PARATEST 1
DBCC FREEPROCCACHE
EXEC DBO.PARATEST 2

-- 이건 또 안되요~
ALTER PROC PARATEST
(@PARA INT)
WITH RECOMPILE
AS
SELECT DISTINCT IDX, COL1, COL2
  FROM TBLX A
 WHERE IDX = @PARA%@PARA+@PARA
GO

EXEC DBO.PARATEST 1
DBCC FREEPROCCACHE
EXEC DBO.PARATEST 2
GO

-- 헉헉~ 끝~

그럼 오늘의 주제로 가봅시다.

IF OBJECT_ID ('TBLX') IS NOT NULL
DROP TABLE TBLX
GO

-- 1000 개의 다른값 넣기
SELECT TOP 1000 ROW_NUMBER() OVER (ORDER BY (SELECT 1)) IDX
 , CAST(ABS(CHECKSUM(NEWID())) AS INT) % 100 COL1
 , CAST('A' AS CHAR(50)) COL2
INTO TBLX
FROM SYS.OBJECTS A1
, SYS.OBJECTS A2
, SYS.OBJECTS A3

CREATE CLUSTERED INDEX CL_TBLX ON TBLX (COL2)
CREATE UNIQUE NONCLUSTERED INDEX NC_TBLX_01 ON TBLX (IDX)

SELECT DISTINCT IDX, COL1
  FROM TBLX

DROP INDEX NC_TBLX_01 ON TBLX

SELECT DISTINCT IDX, COL1
  FROM TBLX

-- 멘붕~ 생각하는 시간

SELECT DISTINCT IDX, COL1
  FROM TBLX
OPTION
(  
  QUERYTRACEON 3604
, QUERYTRACEON 9292 -- 고려될 수 있는 대상 (HEADER 만 LOAD)
, QUERYTRACEON 9204 -- CARDINALITY DISTRIBUTION
, RECOMPILE
)

select * from sys.stats where object_id = object_id ('tblx')

dbcc show_statistics (tblx, _WA_Sys_00000002_25869641)
dbcc show_statistics (tblx, _WA_Sys_00000001_25869641)

-- 효과적으로 질문하기 위해서 이런 현상을 악의축에게 전달 하고자 할 때
-- 어떻게 해야 하는가? 쉬어~ 바바~


 

Posted by 보미아빠
, |

라는 주제를 가지고 어떻게하면 좋을까 고민을 몇일 했는데 만철군이 찾아줬다.

역시 구글을 뒤져야해.....ㅠ.ㅠ 세상엔 똑똑한 사람이 넘 많다~ 역쉬 뒤지는게 더 빠른듯~

 

http://sqlblog.com/blogs/paul_white/archive/2011/09/21/how-to-find-the-statistics-used-to-compile-an-execution-plan.aspx

 

http://www.benjaminnevarez.com/tag/trace-flags/

 

 

A technical SQL Server blog from New Zealand.

How to Find the Statistics Used to Compile an Execution Plan

In this post, I show you how to determine exactly which statistics objects were used by the query optimizer to produce an execution plan.

Trace Flags

We will need three undocumented trace flags. The first one (3604) is well-known – it redirects trace output to the client so it appears in the SSMS messages tab.

The second trace flag is 9292. With this enabled, we get a report of statistics objects which are considered ‘interesting’ by the query optimizer when compiling, or recompiling the query in question. For potentially useful statistics, just the header is loaded.

The third trace flag is 9204. With this enabled, we see the ‘interesting’ statistics which end up being fully loaded and used to produce cardinality and distribution estimates for some plan alternative or other. Again, this only happens when a plan is compiled or recompiled – not when a plan is retrieved from cache.

You can enable and disable these flags with the usual DBCC TRACEON and TRACEOFF commands, but it is also possible to enable them just for a particular statement using the undocumented QUERYTRACEON query hint (demonstrated below).

Sample Query

DBCC FREEPROCCACHE
 
SELECT 
    p.Name,
    total_quantity = SUM(th.Quantity)
FROM AdventureWorks.Production.Product AS p
JOIN AdventureWorks.Production.TransactionHistory AS th ON
    th.ProductID = p.ProductID
WHERE
    th.ActualCost >= $5.00
    AND p.Color = N'Red'
GROUP BY
    p.Name
ORDER BY
    p.Name
OPTION
(
    QUERYTRACEON 3604,
    QUERYTRACEON 9292,
    QUERYTRACEON 9204
)

The DBCC FREEPROCCACHE is just there to empty the plan cache so we get a compilation. You can also evict the current plan from cache if you know its handle (SQL Server 2008) or use a RECOMPILE query hint. Using RECOMPILE is often convenient, but you may get a different plan compared to that obtained without the hint. Note that compiling the query is enough – we do not need to execute the query; simply requesting an ‘estimated plan’ will do. It doesn’t hurt to run it either though, just to be clear.

Sample Output

Stats header loaded: 
    DbName: AdventureWorks, 
    ObjName: AdventureWorks.Production.Product, 
    IndexId: 1, 
    ColumnName: ProductID, 
    EmptyTable: FALSE
 
Stats loaded: 
    DbName: AdventureWorks, 
    ObjName: AdventureWorks.Production.Product, 
    IndexId: 1, 
    ColumnName: ProductID, 
    EmptyTable: FALSE
 
Stats header loaded: 
    DbName: AdventureWorks, 
    ObjName: AdventureWorks.Production.Product, 
    IndexId: 3, 
    ColumnName: Name, 
    EmptyTable: FALSE
 
Stats loaded: 
    DbName: AdventureWorks, 
    ObjName: AdventureWorks.Production.Product, 
    IndexId: 3, 
    ColumnName: Name, 
    EmptyTable: FALSE
 
Stats header loaded: 
    DbName: AdventureWorks, 
    ObjName: AdventureWorks.Production.Product, 
    IndexId: 11, 
    ColumnName: Color, 
    EmptyTable: FALSE
 
Stats loaded: 
    DbName: AdventureWorks, 
    ObjName: AdventureWorks.Production.Product, 
    IndexId: 11, 
    ColumnName: Color, 
    EmptyTable: FALSE
 
Stats header loaded: 
    DbName: AdventureWorks, 
    ObjName: AdventureWorks.Production.TransactionHistory, 
    IndexId: 2, 
    ColumnName: ProductID, 
    EmptyTable: FALSE
 
Stats loaded: 
    DbName: AdventureWorks, 
    ObjName: AdventureWorks.Production.TransactionHistory, 
    IndexId: 2, 
    ColumnName: ProductID, 
    EmptyTable: FALSE
 
Stats header loaded: 
    DbName: AdventureWorks, 
    ObjName: AdventureWorks.Production.TransactionHistory, 
    IndexId: 5, 
    ColumnName: ActualCost, 
    EmptyTable: FALSE
 
Stats loaded: 
    DbName: AdventureWorks, 
    ObjName: AdventureWorks.Production.TransactionHistory, 
    IndexId: 5, 
    ColumnName: ActualCost, 
    EmptyTable: FALSE

There’s no sign of an official way to get this very useful information in Denali, despite it being requested many times over the years. Trace flag 9204 works at least as far back as SQL Server 2005. Both 92xx flags work in 2008, R2, and Denali CTP 3.

Enjoy!

Posted by 보미아빠
, |

sitelist

카테고리 없음 / 2013. 3. 22. 01:07

하나하나 추가 해야쥐~

 

http://sql-blogs.com/

http://technet.microsoft.com/en-us/library/cc298801%28v=office.14%29.aspx

 

   

http://blogs.msdn.com/b/sql_pfe_blog/archive/2013/04/15/sql-2012-system-health-reporting-dashboard-visualizing-sp-server-diagnostics-results.aspx

 

http://blogs.msdn.com/b/ntdebugging/archive/2008/04/03/windows-performance-toolkit-xperf.aspx

Posted by 보미아빠
, |

최근에 달린 댓글

최근에 받은 트랙백

글 보관함