'memory'에 해당되는 글 2건
- 2012.08.13 실행 쿼리 memory 사용 대기 정보 1
- 2010.12.28 Admin::Configuring Windows 2003 ( x64 ) for SQL Server
실행 쿼리 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 |
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?
'Common Admin' 카테고리의 다른 글
Admin:: SQL Server 에러로 다른 서버에서 Rebuilding 처리 (0) | 2011.08.14 |
---|---|
Admin::Cache Flush 가 발생하는 경우 (0) | 2011.03.30 |
Admin:: LOG Rebuild (0) | 2010.11.23 |
waitresource 값 확인 (0) | 2010.11.01 |