SQL Server 运行状况监控SQL语句

 

Microsoft SQL Server 2005 提供了一些工具来监控数据库。方法之一是动态管理视图。动态管理视图 (DMV) 和动态管理函数 (DMF) 返回的服务器状态信息可用于监控服务器实例的运行状况、诊断问题和优化性能。

常规服务器动态管理对象包括：

  • dm_db_*：数据库和数据库对象
  • dm_exec_*：执行用户代码和关联的连接
  • dm_os_*：内存、锁定和时间安排
  • dm_tran_*：事务和隔离
  • dm_io_*：网络和磁盘的输入/输出

此部分介绍为监控 SQL Server 运行状况而针对这些动态管理视图和函数运行的一些常用查询。

示例查询

您可以运行以下查询来获取所有 DMV 和 DMF 名称：

  1. SELECT * FROM sys.system_objects
  2. WHERE name LIKE 'dm_%'
  3. ORDER BY name

监控 CPU 瓶颈

CPU 瓶颈通常由以下原因引起：查询计划并非最优、配置不当、设计因素不良或硬件资源不足。下面的常用查询可帮助您确定导致 CPU 瓶颈的原因。

下面的查询使您能够深入了解当前缓存的哪些批处理或过程占用了大部分 CPU 资源。

  1. SELECT TOP 50
  2.       SUM(qs.total_worker_time) AS total_cpu_time,
  3.       SUM(qs.execution_count) AS total_execution_count,
  4.       COUNT(*) AS  number_of_statements,
  5.       qs.sql_handle
  6. FROM sys.dm_exec_query_stats AS qs
  7. GROUP BY qs.sql_handle
  8. ORDER BY SUM(qs.total_worker_time) DESC

下面的查询显示缓存计划所占用的 CPU 总使用率（带 SQL 文本）。

  1. SELECT
  2.       total_cpu_time,
  3.       total_execution_count,
  4.       number_of_statements,
  5.       s2.text
  6.       --(SELECT SUBSTRING(s2.text, statement_start_offset / 2, ((CASE WHEN statement_end_offset = -1 THEN (LEN(CONVERT(NVARCHAR(MAX), s2.text)) * 2) ELSE statement_end_offset END) - statement_start_offset) / 2) ) AS query_text
  7. FROM
  8.       (SELECT TOP 50
  9.             SUM(qs.total_worker_time) AS total_cpu_time,
  10.             SUM(qs.execution_count) AS total_execution_count,
  11.             COUNT(*) AS  number_of_statements,
  12.             qs.sql_handle --,
  13.             --MIN(statement_start_offset) AS statement_start_offset,
  14.             --MAX(statement_end_offset) AS statement_end_offset
  15.       FROM
  16.             sys.dm_exec_query_stats AS qs
  17.       GROUP BY qs.sql_handle
  18.       ORDER BY SUM(qs.total_worker_time) DESC) AS stats
  19.       CROSS APPLY sys.dm_exec_sql_text(stats.sql_handle) AS s2

下面的查询显示 CPU 平均占用率最高的前 50 个 SQL 语句。

 

  1. SELECT TOP 50
  2. total_worker_time/execution_count AS [Avg CPU Time],
  3. (SELECT SUBSTRING(text,statement_start_offset/2,
  4. (CASE WHEN statement_end_offset = -1 then LEN(CONVERT(nvarchar(max), text)) * 2 ELSE statement_end_offset end -statement_start_offset)/2)
  5. FROM sys.dm_exec_sql_text(sql_handle)) AS query_text, *
  6. FROM sys.dm_exec_query_stats
  7. ORDER BY [Avg CPU Time] DESC

下面显示用于找出过多编译/重新编译的 DMV 查询。

  1. select * from sys.dm_exec_query_optimizer_info
  2. where  counter = 'optimizations' or counter = 'elapsed time'

下面的示例查询显示已重新编译的前 25 个存储过程。plan_generation_num 指示该查询已重新编译的次数。

  1. select top 25
  2.       sql_text.text,
  3.       sql_handle,
  4.       plan_generation_num,
  5.       execution_count,
  6.       dbid,
  7.       objectid
  8. from sys.dm_exec_query_stats a
  9.       cross apply sys.dm_exec_sql_text(sql_handle) as sql_text
  10. where plan_generation_num > 1
  11. order by plan_generation_num desc

效率较低的查询计划可能增大 CPU 占用率。下面的查询显示哪个查询占用了最多的 CPU 累计使用率。

 
 
  1. SELECT
  2.     highest_cpu_queries.plan_handle,
  3.     highest_cpu_queries.total_worker_time,
  4.     q.dbid,
  5.     q.objectid,
  6.     q.number,
  7.     q.encrypted,
  8.     q.[text]
  9. from
  10.     (select top 50
  11.         qs.plan_handle,
  12.         qs.total_worker_time
  13.     from
  14.         sys.dm_exec_query_stats qs
  15.     order by qs.total_worker_time desc) as highest_cpu_queries
  16.     cross apply sys.dm_exec_sql_text(plan_handle) as q
  17. order by highest_cpu_queries.total_worker_time desc

下面的查询显示一些可能占用大量 CPU 使用率的运算符（例如 ‘%Hash Match%’、‘%Sort%’）以找出可疑对象。

 
 
  1. select *
  2. from
  3.       sys.dm_exec_cached_plans
  4.       cross apply sys.dm_exec_query_plan(plan_handle)
  5. where
  6.       cast(query_plan as nvarchar(max)) like '%Sort%'
  7.       or cast(query_plan as nvarchar(max)) like '%Hash Match%'

如果已检测到效率低下并导致 CPU 占用率较高的查询计划，请对该查询中涉及的表运行 UPDATE STATISTICS 以查看该问题是否仍然存在。然后，收集相关数据并将此问题报告给 PerformancePoint 规划支持人员。

如果您的系统存在过多的编译和重新编译，可能会导致系统出现与 CPU 相关的性能问题。

您可以运行下面的 DMV 查询来找出过多的编译/重新编译。

 
 
  1. select * from sys.dm_exec_query_optimizer_info
  2. where
  3. counter = 'optimizations'
  4. or counter = 'elapsed time'

下面的示例查询显示已重新编译的前 25 个存储过程。plan_generation_num 指示该查询已重新编译的次数。

 
 
  1. select top 25
  2. sql_text.text,
  3. sql_handle,
  4. plan_generation_num,
  5. execution_count,
  6. dbid,
  7. objectid
  8. from sys.dm_exec_query_stats a
  9. cross apply sys.dm_exec_sql_text(sql_handle) as sql_text
  10. where plan_generation_num > 1
  11. order by plan_generation_num desc

如果已检测到过多的编译或重新编译，请尽可能多地收集相关数据并将其报告给规划支持人员

内存瓶颈

开始内存压力检测和调查之前，请确保已启用 SQL Server 中的高级选项。请先对 master 数据库运行以下查询以启用此选项。

 
 
  1. sp_configure 'show advanced options'
  2. go
  3. sp_configure 'show advanced options', 1
  4. go
  5. reconfigure
  6. go

首先运行以下查询以检查内存相关配置选项。

 
 
  1. sp_configure 'awe_enabled'
  2. go
  3. sp_configure 'min server memory'
  4. go
  5. sp_configure 'max server memory'
  6. go
  7. sp_configure 'min memory per query'
  8. go
  9. sp_configure 'query wait'
  10. go

运行下面的 DMV 查询以查看 CPU、计划程序内存和缓冲池信息。

 
 
  1. select
  2. cpu_count,
  3. hyperthread_ratio,
  4. scheduler_count,
  5. physical_memory_in_bytes / 1024 / 1024 as physical_memory_mb,
  6. virtual_memory_in_bytes / 1024 / 1024 as virtual_memory_mb,
  7. bpool_committed * 8 / 1024 as bpool_committed_mb,
  8. bpool_commit_target * 8 / 1024 as bpool_target_mb,
  9. bpool_visible * 8 / 1024 as bpool_visible_mb
  10. from sys.dm_os_sys_info

I/O 瓶颈

检查闩锁等待统计信息以确定 I/O 瓶颈。运行下面的 DMV 查询以查找 I/O 闩锁等待统计信息。

 
 
  1. select wait_type, waiting_tasks_count, wait_time_ms, signal_wait_time_ms, wait_time_ms / waiting_tasks_count
  2. from sys.dm_os_wait_stats 
  3. where wait_type like 'PAGEIOLATCH%'  and waiting_tasks_count > 0
  4. order by wait_type

如果 waiting_task_counts 和 wait_time_ms 与正常情况相比有显著变化，则可以确定存在 I/O 问题。获取 SQL Server 平稳运行时性能计数器和主要 DMV 查询输出的基线非常重要。

这些 wait_types 可以指示您的 I/O 子系统是否遇到瓶颈。

使用以下 DMV 查询来查找当前挂起的 I/O 请求。请定期执行此查询以检查 I/O 子系统的运行状况，并隔离 I/O 瓶颈中涉及的物理磁盘。

 
 
  1. select
  2.     database_id,
  3.     file_id,
  4.     io_stall,
  5.     io_pending_ms_ticks,
  6.     scheduler_address
  7. from  sys.dm_io_virtual_file_stats(NULL, NULL)t1,
  8.         sys.dm_io_pending_io_requests as t2
  9. where t1.file_handle = t2.io_handle

在正常情况下，该查询通常不返回任何内容。如果此查询返回一些行，则需要进一步调查。

您还可以执行下面的 DMV 查询以查找 I/O 相关查询。

 
 
  1. select top 5 (total_logical_reads/execution_count) as avg_logical_reads,
  2.                    (total_logical_writes/execution_count) as avg_logical_writes,
  3.            (total_physical_reads/execution_count) as avg_physical_reads,
  4.            Execution_count, statement_start_offset, p.query_plan, q.text
  5. from sys.dm_exec_query_stats
  6.       cross apply sys.dm_exec_query_plan(plan_handle) p
  7.       cross apply sys.dm_exec_sql_text(plan_handle) as q
  8. order by (total_logical_reads + total_logical_writes)/execution_count Desc

下面的 DMV 查询可用于查找哪些批处理/请求生成的 I/O 最多。如下所示的 DMV 查询可用于查找可生成最多 I/O 的前五个请求。调整这些查询将提高系统性能。

 
 
  1. select top 5
  2.     (total_logical_reads/execution_count) as avg_logical_reads,
  3.     (total_logical_writes/execution_count) as avg_logical_writes,
  4.     (total_physical_reads/execution_count) as avg_phys_reads,
  5.      Execution_count,
  6.     statement_start_offset as stmt_start_offset,
  7.     sql_handle,
  8.     plan_handle
  9. from sys.dm_exec_query_stats 
  10. order by  (total_logical_reads + total_logical_writes) Desc

阻塞

运行下面的查询可确定阻塞的会话。

 
 
  1. select blocking_session_id, wait_duration_ms, session_id from
  2. sys.dm_os_waiting_tasks
  3. where blocking_session_id is not null

使用此调用可找出 blocking_session_id 所返回的 SQL。例如，如果 blocking_session_id 是 87，则运行此查询可获得相应的 SQL。

 
 
  1. dbcc INPUTBUFFER(87)

下面的查询显示 SQL 等待分析和前 10 个等待的资源。

 
 
  1. select top 10 *
  2. from sys.dm_os_wait_stats
  3. --where wait_type not in ('CLR_SEMAPHORE','LAZYWRITER_SLEEP','RESOURCE_QUEUE','SLEEP_TASK','SLEEP_SYSTEMTASK','WAITFOR')
  4. order by wait_time_ms desc

若要找出哪个 spid 正在阻塞另一个 spid，可在数据库中创建以下存储过程，然后执行该存储过程。此存储过程会报告此阻塞情况。键入 sp_who 可找出 @spid；@spid 是可选参数。

 
 
  1. create proc dbo.sp_block (@spid bigint=NULL)
  2. as
  3. select
  4.     t1.resource_type,
  5.     'database'=db_name(resource_database_id),
  6.     'blk object' = t1.resource_associated_entity_id,
  7.     t1.request_mode,
  8.     t1.request_session_id,
  9.     t2.blocking_session_id   
  10. from
  11.     sys.dm_tran_locks as t1,
  12.     sys.dm_os_waiting_tasks as t2
  13. where
  14.     t1.lock_owner_address = t2.resource_address and
  15.     t1.request_session_id = isnull(@spid,t1.request_session_id)

以下是使用此存储过程的示例。

 
 
  1. exec sp_block
  2. exec sp_block @spid = 7
  3.  
  4. 转载：https://www.cnblogs.com/MuNet/p/6781708.html

SQL Server 运行状况监控SQL语句

 

Microsoft SQL Server 2005 提供了一些工具来监控数据库。方法之一是动态管理视图。动态管理视图 (DMV) 和动态管理函数 (DMF) 返回的服务器状态信息可用于监控服务器实例的运行状况、诊断问题和优化性能。

常规服务器动态管理对象包括：

  • dm_db_*：数据库和数据库对象
  • dm_exec_*：执行用户代码和关联的连接
  • dm_os_*：内存、锁定和时间安排
  • dm_tran_*：事务和隔离
  • dm_io_*：网络和磁盘的输入/输出

此部分介绍为监控 SQL Server 运行状况而针对这些动态管理视图和函数运行的一些常用查询。

示例查询

您可以运行以下查询来获取所有 DMV 和 DMF 名称：

  1. SELECT * FROM sys.system_objects
  2. WHERE name LIKE 'dm_%'
  3. ORDER BY name

监控 CPU 瓶颈

CPU 瓶颈通常由以下原因引起：查询计划并非最优、配置不当、设计因素不良或硬件资源不足。下面的常用查询可帮助您确定导致 CPU 瓶颈的原因。

下面的查询使您能够深入了解当前缓存的哪些批处理或过程占用了大部分 CPU 资源。

  1. SELECT TOP 50
  2.       SUM(qs.total_worker_time) AS total_cpu_time,
  3.       SUM(qs.execution_count) AS total_execution_count,
  4.       COUNT(*) AS  number_of_statements,
  5.       qs.sql_handle
  6. FROM sys.dm_exec_query_stats AS qs
  7. GROUP BY qs.sql_handle
  8. ORDER BY SUM(qs.total_worker_time) DESC

下面的查询显示缓存计划所占用的 CPU 总使用率（带 SQL 文本）。

  1. SELECT
  2.       total_cpu_time,
  3.       total_execution_count,
  4.       number_of_statements,
  5.       s2.text
  6.       --(SELECT SUBSTRING(s2.text, statement_start_offset / 2, ((CASE WHEN statement_end_offset = -1 THEN (LEN(CONVERT(NVARCHAR(MAX), s2.text)) * 2) ELSE statement_end_offset END) - statement_start_offset) / 2) ) AS query_text
  7. FROM
  8.       (SELECT TOP 50
  9.             SUM(qs.total_worker_time) AS total_cpu_time,
  10.             SUM(qs.execution_count) AS total_execution_count,
  11.             COUNT(*) AS  number_of_statements,
  12.             qs.sql_handle --,
  13.             --MIN(statement_start_offset) AS statement_start_offset,
  14.             --MAX(statement_end_offset) AS statement_end_offset
  15.       FROM
  16.             sys.dm_exec_query_stats AS qs
  17.       GROUP BY qs.sql_handle
  18.       ORDER BY SUM(qs.total_worker_time) DESC) AS stats
  19.       CROSS APPLY sys.dm_exec_sql_text(stats.sql_handle) AS s2

下面的查询显示 CPU 平均占用率最高的前 50 个 SQL 语句。

 

  1. SELECT TOP 50
  2. total_worker_time/execution_count AS [Avg CPU Time],
  3. (SELECT SUBSTRING(text,statement_start_offset/2,
  4. (CASE WHEN statement_end_offset = -1 then LEN(CONVERT(nvarchar(max), text)) * 2 ELSE statement_end_offset end -statement_start_offset)/2)
  5. FROM sys.dm_exec_sql_text(sql_handle)) AS query_text, *
  6. FROM sys.dm_exec_query_stats
  7. ORDER BY [Avg CPU Time] DESC

下面显示用于找出过多编译/重新编译的 DMV 查询。

  1. select * from sys.dm_exec_query_optimizer_info
  2. where  counter = 'optimizations' or counter = 'elapsed time'

下面的示例查询显示已重新编译的前 25 个存储过程。plan_generation_num 指示该查询已重新编译的次数。

  1. select top 25
  2.       sql_text.text,
  3.       sql_handle,
  4.       plan_generation_num,
  5.       execution_count,
  6.       dbid,
  7.       objectid
  8. from sys.dm_exec_query_stats a
  9.       cross apply sys.dm_exec_sql_text(sql_handle) as sql_text
  10. where plan_generation_num > 1
  11. order by plan_generation_num desc

效率较低的查询计划可能增大 CPU 占用率。下面的查询显示哪个查询占用了最多的 CPU 累计使用率。

 
 
  1. SELECT
  2.     highest_cpu_queries.plan_handle,
  3.     highest_cpu_queries.total_worker_time,
  4.     q.dbid,
  5.     q.objectid,
  6.     q.number,
  7.     q.encrypted,
  8.     q.[text]
  9. from
  10.     (select top 50
  11.         qs.plan_handle,
  12.         qs.total_worker_time
  13.     from
  14.         sys.dm_exec_query_stats qs
  15.     order by qs.total_worker_time desc) as highest_cpu_queries
  16.     cross apply sys.dm_exec_sql_text(plan_handle) as q
  17. order by highest_cpu_queries.total_worker_time desc

下面的查询显示一些可能占用大量 CPU 使用率的运算符（例如 ‘%Hash Match%’、‘%Sort%’）以找出可疑对象。

 
 
  1. select *
  2. from
  3.       sys.dm_exec_cached_plans
  4.       cross apply sys.dm_exec_query_plan(plan_handle)
  5. where
  6.       cast(query_plan as nvarchar(max)) like '%Sort%'
  7.       or cast(query_plan as nvarchar(max)) like '%Hash Match%'

如果已检测到效率低下并导致 CPU 占用率较高的查询计划，请对该查询中涉及的表运行 UPDATE STATISTICS 以查看该问题是否仍然存在。然后，收集相关数据并将此问题报告给 PerformancePoint 规划支持人员。

如果您的系统存在过多的编译和重新编译，可能会导致系统出现与 CPU 相关的性能问题。

您可以运行下面的 DMV 查询来找出过多的编译/重新编译。

 
 
  1. select * from sys.dm_exec_query_optimizer_info
  2. where
  3. counter = 'optimizations'
  4. or counter = 'elapsed time'

下面的示例查询显示已重新编译的前 25 个存储过程。plan_generation_num 指示该查询已重新编译的次数。

 
 
  1. select top 25
  2. sql_text.text,
  3. sql_handle,
  4. plan_generation_num,
  5. execution_count,
  6. dbid,
  7. objectid
  8. from sys.dm_exec_query_stats a
  9. cross apply sys.dm_exec_sql_text(sql_handle) as sql_text
  10. where plan_generation_num > 1
  11. order by plan_generation_num desc

如果已检测到过多的编译或重新编译，请尽可能多地收集相关数据并将其报告给规划支持人员

内存瓶颈

开始内存压力检测和调查之前，请确保已启用 SQL Server 中的高级选项。请先对 master 数据库运行以下查询以启用此选项。

 
 
  1. sp_configure 'show advanced options'
  2. go
  3. sp_configure 'show advanced options', 1
  4. go
  5. reconfigure
  6. go

首先运行以下查询以检查内存相关配置选项。

 
 
  1. sp_configure 'awe_enabled'
  2. go
  3. sp_configure 'min server memory'
  4. go
  5. sp_configure 'max server memory'
  6. go
  7. sp_configure 'min memory per query'
  8. go
  9. sp_configure 'query wait'
  10. go

运行下面的 DMV 查询以查看 CPU、计划程序内存和缓冲池信息。

 
 
  1. select
  2. cpu_count,
  3. hyperthread_ratio,
  4. scheduler_count,
  5. physical_memory_in_bytes / 1024 / 1024 as physical_memory_mb,
  6. virtual_memory_in_bytes / 1024 / 1024 as virtual_memory_mb,
  7. bpool_committed * 8 / 1024 as bpool_committed_mb,
  8. bpool_commit_target * 8 / 1024 as bpool_target_mb,
  9. bpool_visible * 8 / 1024 as bpool_visible_mb
  10. from sys.dm_os_sys_info

I/O 瓶颈

检查闩锁等待统计信息以确定 I/O 瓶颈。运行下面的 DMV 查询以查找 I/O 闩锁等待统计信息。

 
 
  1. select wait_type, waiting_tasks_count, wait_time_ms, signal_wait_time_ms, wait_time_ms / waiting_tasks_count
  2. from sys.dm_os_wait_stats 
  3. where wait_type like 'PAGEIOLATCH%'  and waiting_tasks_count > 0
  4. order by wait_type

如果 waiting_task_counts 和 wait_time_ms 与正常情况相比有显著变化，则可以确定存在 I/O 问题。获取 SQL Server 平稳运行时性能计数器和主要 DMV 查询输出的基线非常重要。

这些 wait_types 可以指示您的 I/O 子系统是否遇到瓶颈。

使用以下 DMV 查询来查找当前挂起的 I/O 请求。请定期执行此查询以检查 I/O 子系统的运行状况，并隔离 I/O 瓶颈中涉及的物理磁盘。

 
 
  1. select
  2.     database_id,
  3.     file_id,
  4.     io_stall,
  5.     io_pending_ms_ticks,
  6.     scheduler_address
  7. from  sys.dm_io_virtual_file_stats(NULL, NULL)t1,
  8.         sys.dm_io_pending_io_requests as t2
  9. where t1.file_handle = t2.io_handle

在正常情况下，该查询通常不返回任何内容。如果此查询返回一些行，则需要进一步调查。

您还可以执行下面的 DMV 查询以查找 I/O 相关查询。

 
 
  1. select top 5 (total_logical_reads/execution_count) as avg_logical_reads,
  2.                    (total_logical_writes/execution_count) as avg_logical_writes,
  3.            (total_physical_reads/execution_count) as avg_physical_reads,
  4.            Execution_count, statement_start_offset, p.query_plan, q.text
  5. from sys.dm_exec_query_stats
  6.       cross apply sys.dm_exec_query_plan(plan_handle) p
  7.       cross apply sys.dm_exec_sql_text(plan_handle) as q
  8. order by (total_logical_reads + total_logical_writes)/execution_count Desc

下面的 DMV 查询可用于查找哪些批处理/请求生成的 I/O 最多。如下所示的 DMV 查询可用于查找可生成最多 I/O 的前五个请求。调整这些查询将提高系统性能。

 
 
  1. select top 5
  2.     (total_logical_reads/execution_count) as avg_logical_reads,
  3.     (total_logical_writes/execution_count) as avg_logical_writes,
  4.     (total_physical_reads/execution_count) as avg_phys_reads,
  5.      Execution_count,
  6.     statement_start_offset as stmt_start_offset,
  7.     sql_handle,
  8.     plan_handle
  9. from sys.dm_exec_query_stats 
  10. order by  (total_logical_reads + total_logical_writes) Desc

阻塞

运行下面的查询可确定阻塞的会话。

 
 
  1. select blocking_session_id, wait_duration_ms, session_id from
  2. sys.dm_os_waiting_tasks
  3. where blocking_session_id is not null

使用此调用可找出 blocking_session_id 所返回的 SQL。例如，如果 blocking_session_id 是 87，则运行此查询可获得相应的 SQL。

 
 
  1. dbcc INPUTBUFFER(87)

下面的查询显示 SQL 等待分析和前 10 个等待的资源。

 
 
  1. select top 10 *
  2. from sys.dm_os_wait_stats
  3. --where wait_type not in ('CLR_SEMAPHORE','LAZYWRITER_SLEEP','RESOURCE_QUEUE','SLEEP_TASK','SLEEP_SYSTEMTASK','WAITFOR')
  4. order by wait_time_ms desc

若要找出哪个 spid 正在阻塞另一个 spid，可在数据库中创建以下存储过程，然后执行该存储过程。此存储过程会报告此阻塞情况。键入 sp_who 可找出 @spid；@spid 是可选参数。

 
 
  1. create proc dbo.sp_block (@spid bigint=NULL)
  2. as
  3. select
  4.     t1.resource_type,
  5.     'database'=db_name(resource_database_id),
  6.     'blk object' = t1.resource_associated_entity_id,
  7.     t1.request_mode,
  8.     t1.request_session_id,
  9.     t2.blocking_session_id   
  10. from
  11.     sys.dm_tran_locks as t1,
  12.     sys.dm_os_waiting_tasks as t2
  13. where
  14.     t1.lock_owner_address = t2.resource_address and
  15.     t1.request_session_id = isnull(@spid,t1.request_session_id)

以下是使用此存储过程的示例。

 
 
  1. exec sp_block
  2. exec sp_block @spid = 7

【转】SQL Server 运行状况监控SQL语句的更多相关文章

  1. SQL Server 运行状况监控SQL语句

    Microsoft SQL Server 2005 提供了一些工具来监控数据库.方法之一是动态管理视图.动态管理视图 (DMV) 和动态管理函数 (DMF) 返回的服务器状态信息可用于监控服务器实例的 ...

  2. 微软官方提供的用于监控MS SQL Server运行状况的工具及SQL语句

    Microsoft SQL Server 2005 提供了一些工具来监控数据库.方法之一是动态管理视图.动态管理视图 (DMV) 和动态管理函数 (DMF) 返回的服务器状态信息可用于监控服务器实例的 ...

  3. 【SQL Server DBA】日常巡检语句3：特定监控(阻塞、top语句、索引、作业)

    原文:[SQL Server DBA]日常巡检语句3:特定监控(阻塞.top语句.索引.作业) 1.查询阻塞信息.锁定了哪些资源 --1.查看阻塞信息 select spid,loginame,wai ...

  4. 监控SQL Server正在执行的SQL语句和死锁情况

    原文:监控SQL Server正在执行的SQL语句和死锁情况 SELECT [Individual Query] = SUBSTRING(qt.TEXT, er.statement_start_off ...

  5. 4. SQL Server数据库状态监控 - 作业状态

    原文:4. SQL Server数据库状态监控 - 作业状态 有很多地方可以设置定时任务,比如:Windows的计划任务,Linux下的crontab,各种开发工具里的timer组件.SQL Serv ...

  6. 2. SQL Server数据库状态监控 - 错误日志

    原文:2. SQL Server数据库状态监控 - 错误日志 无论是操作系统 (Unix 或者Windows),还是应用程序 (Web 服务,数据库系统等等) ,通常都有自身的日志机制,以便故障时追溯 ...

  7. 5. SQL Server数据库性能监控 - 当前请求

    原文:5. SQL Server数据库性能监控 - 当前请求 对于在线运行的系统,当前数据库性能监控,通常监视以下几点: (1) 是否有阻塞 (Blocking); (2) 是否有等待 (Waitin ...

  8. 3. SQL Server数据库状态监控 - 可用空间

    原文:3. SQL Server数据库状态监控 - 可用空间 数据库用来存放数据,那么肯定需要存储空间,所以对磁盘空间的监视自然就很有必要了. 一. 磁盘可用空间 1. 操作系统命令或脚本.接口或工具 ...

  9. SQL Server 运行计划操作符具体解释（2）——串联(Concatenation )

    本文接上文:SQL Server 运行计划操作符具体解释(1)--断言(Assert) 前言: 依据计划.本文開始讲述另外一个操作符串联(Concatenation).读者能够依据这个词(中英文均可) ...

随机推荐

  1. 2018/03/07 每日一个Linux命令 之 cat

    每日一个Linux命令 2018-03-07 Linux 命令 cat cat [-参数] fileName 在之前的Linux使用中 cat 命令一直作为文本输出指令来使用,很少可以深入学习的该命令 ...

  2. java 数组（一）

    java的数组操作和C#是一样的,不多说明. public class ArrayDemo{ public static void main(String[] args){ //数组的定义 数据类型[ ...

  3. MapStruct

    一.Object mapping 的技术分类: 运行期 反射调用set/get 或者是直接对成员变量赋值 . 该方式通过invoke执行赋值,实现时一般会采用beanutil, Javassist等开 ...

  4. 【JMeter】基础元件

    测试计划(Test Plan) 它用来描述一个测试方案,包含与本次性能测试所有相关的功能.也就说本次测试的所有内容是于基于一个计划的. “函数测试模式”复选框,如果被选择,它会使Jmeter记录来自服 ...

  5. 所使用的“System.Web.Mvc, Version=3.0.0.1, Culture=neutral, PublicKeyToken=31bf3856ad364e35”版本高于所引用的程序集“System.Web.Mvc, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35”的版本

    System.Web.Mvc.dll引用是感叹号. 解决方法:新建mv3应用程序,右键选择System.Web.Mvc.dll 查看所引用的路径. 在旧程序中重新引用即可.C:\Program Fil ...

  6. finecms如何调用多个栏目的子栏目

    前面我们说到了finecms如何调用多个指定栏目的内容,finecms如何调用多个栏目的子栏目呢?用下面的代码就可以实现了,其中id是具体的栏目id,用“,”逗号隔开 {list action=cat ...

  7. Linux-pkill命令

    pkill命令可以按照进程名杀死进程.pkill和killall应用方法差不多,也是直接杀死运行中的程序:如果您想杀掉单个进程,请用kill来杀掉. 语法:pkill(选项)(参数) 选项 -o:仅向 ...

  8. SSM基础整合

    1.表现层: 依赖jar包:spring+JSP+文件上传组件+dubbo+fastdfs web.xml配置:乱码过滤器+DispatcherServlet前端控制器 <!-- 配置post乱 ...

  9. Py中reshape中的-1表示什么【转载】

    转自:https://blog.csdn.net/weixin_39449570/article/details/78619196 1.新数组的shape属性应该要与原来数组的一致,即新数组元素数量与 ...

  10. sync修饰符的简易说明

    其实这个就说的很好了. sync会自动更新父组件的数据 原本valuechild 的值是222,父页面显示的222,把值传递给子组件 子组件也显示的222, 我点击子组件的按钮 把333传递给父组件, ...