2012. 8. 13. 18:21

실행 쿼리 memory 사용 대기 정보

SQL SERVER 2005 이상. - 일부 컬럼은 SQL 2008 이상



메모리 사용을 대기하는 쿼리의 정보를 반환합니다. 

메모리 대기를 하지 않는 쿼리는 나타나지 않으며, 이 쿼리에 실행되는 내역이 많다면 메모리 할당 대기가 많다는 의미 입니다. 



-- memory used
select top 50
  --mem.session_id,req.group_id, -- sql 2008 이상 가능
  db_name(req.database_id) as db,
  mem.request_time, mem.grant_time,
  mem.granted_memory_kb,mem.used_memory_kb, mem.required_memory_kb, 
  mem.query_cost,mem.timeout_sec,mem.wait_time_ms as 'wait_time',
  object_schema_name(sql_text.objectid,sql_text.dbid) as schema_n,
  object_name(sql_text.objectid, sql_text.dbid) as spname,
  CASE WHEN   req.statement_end_offset = -1 and ( (req.statement_start_offset / 2)  > DATALENGTH (sql_text.text) )
            THEN  convert(varchar(4000), 
                 substring(isnull(sql_text.text, '') 
               , 1, ( ( DATALENGTH (sql_text.text) - 1 )/2 ) + 1 ) )
            ELSE  convert(varchar(4000), substring(isnull(sql_text.text, '') 
             , (req.statement_start_offset / 2) + 1
             , (( case when req.statement_end_offset = -1 then DATALENGTH (sql_text.text) else req.statement_end_offset end 
               - req.statement_start_offset ) /2 ) + 1) )
            END  as query_text,
  ses.login_name, ses.host_name, ses.program_name,
  mem.scheduler_id
from sys.dm_exec_requests as req with (nolock)
  join sys.dm_exec_sessions as ses with (nolock) on req.session_id = ses.session_id
  join sys.dm_exec_query_memory_grants as mem with (nolock) on req.request_id = mem.request_id
    and ses.session_id = mem.session_id
  cross apply sys.dm_exec_sql_text(req.sql_handle) as sql_text
where ses.is_user_process = 1  and wait_type <> 'WAITFOR' 
  --and req.database_id = db_id('tiger')
  -- and mem.grant_time is null -- not allocation 
order by used_memory_kb desc

'Monitoring' 카테고리의 다른 글

Tempdb 공간 사용 확인  (0) 2013.09.13
대랑 I/O 사용 세션 쿼리  (0) 2012.08.13
TEMPDB의 페이지 사용량 측정  (0) 2012.08.13
모니터링::Index 생성 & Rebuild 진행 상황  (0) 2011.12.06
2010. 12. 28. 11:41

Admin::Configuring Windows 2003 ( x64 ) for SQL Server


http://sqlblogcasts.com/blogs/grumpyolddba/archive/2008/01/06/configuring-windows-2003-x64-for-sql-server.aspx


So let’s consider memory first; x64 with 32gb ram, we can allocate 2 to 4 gb to the o/s and give the rest to SQL Server, or this is what we believe? Well not really.

 Let’s say this is a 4 way dual core box, windows will allocate 576 work threads, each of which requires 2mb of memory. In the illustration I viewed the calculations go thus:-
  • Let's leave 2GB for the OS and other applications: 2GB
  • And let's allocate 2GB for the MPA / Thread Stacks / Linked Servers etc: 2GB
  • And finally, let's reserve 3GB for all the other applications on the server (AV, backup etc): 3GB
  • So now our max server memory setting is: 32-2-2-3 = 25GB
  • Remember - this is a baseline calculation

The average Enterprise SQL Server will likely have fibre channel HBAs, be SAN attached, probably have teamed / load balanced HBAs and NICs, will have a suite of hardware monitoring programs, will have an Antivirus, will be running a monitoring program such as Tivoli or MOM and will probably have other agents and services running as part of your standard build. You may well have IIS, reporting services, SSIS, old dts, full text. Do you really believe these can all run within 2gb – including the operating system?