数据库数据流量太大-问题诊断

问题:

运维报告某一台数据库,数据流量太大,具体数值不清楚。超过其他正常数据库的流量。

问题分析:

数据流量过大,猜测是一是数据库访问量增加(可能性不大,基本排除),二是某些项目的sql查询了单表的大量数据。有可能是查询条件筛选访问过大。

公司项目:

dotnet4.5、entityframe work 6.1.3、sqlServer

处理方法:

1,sqlServer  统计查询返回的数据量

https://docs.microsoft.com/zh-cn/sql/relational-databases/system-dynamic-management-views/sys-dm-exec-query-stats-transact-sql?view=sql-server-2017

SELECT TOP 50
qs.total_worker_time/qs.execution_count as [Avg CPU Time],
SUBSTRING(qt.text,qs.statement_start_offset/2,
(case when qs.statement_end_offset = -1
then len(convert(nvarchar(max), qt.text)) * 2
else qs.statement_end_offset end -qs.statement_start_offset)/2)
as query_text,
qt.dbid, dbname=db_name(qt.dbid),
qt.objectid ,
qs.total_rows,qs.last_rows ,qs.max_rows ,qs.min_rows
FROM sys.dm_exec_query_stats qs
cross apply sys.dm_exec_sql_text(qs.sql_handle) as qt
ORDER BY total_rows DESC;

2,经以上查询,发现有一张表的查询sql,无where条件。

再对对应的项目,进行代码核查,发现Entity FrameWork中where条件未生成。

具体代码不在我手里。无EF业务代码。

where条件生成原理,请查看Entity FrameWork的具体细节。

原文地址:https://www.cnblogs.com/suzixuan/p/12600432.html

时间: 2024-10-12 21:34:11

数据库数据流量太大-问题诊断的相关文章

测试用的数据库Transaction Log太大, 用于缩减它的脚本

记在这里, 备用. select name, recovery_model_desc from sys.databases where name = 'WSS_Content_1000' USE WSS_Content_1000 ; ALTER DATABASE WSS_Content_1000 SET RECOVERY Simple; go use WSS_Content_1000 go checkpoint go checkpoint go dbcc shrinkfile(WSS_Conte

SQL SERVER 数据日志太大,磁盘没有空间,直接删除数据库日志后,显示 恢复挂起。

问题简述: sharepoint的某个站点对应的数据库日志太大了,想把日志瘦身.于是我把整个数据库分离,然后附加数据库来重新生成日志文件.谁知道在附加的时候,居然报错"附加数据库报错:由于数据库没有完全关闭,无法重新生成日志" 问题原因:原因是数据库关闭时存在打开的事务/用户,该数据库没有检查点或者该数据库是只读的.如果事务日志文件被手动删除或者由于硬件或环境问题而丢失,则可能出现此错误. 处理办法: 一.把分离之前的日志文件也复制过来一齐附加嘛从错误提示看, 应该是你的日志文件中还包

导入数据 文件太大 报错

在sql 文件头部,写入这几个信息即可 set global max_allowed_packet=100000000;set global net_buffer_length=100000;SET GLOBAL interactive_timeout=28800000;SET GLOBAL wait_timeout=28800000;

单实例,当MongoDB单表数据文件太大导致写入速度变慢

解决办法(待测试): 文件拆分成小文件.主要参数有 Storage options: --storageEngine arg what storage engine to use - defaults to wiredTiger if no data files present --directoryperdb each database will be stored in a separate directory --quota limits each database to a certai

数据库性能优化一:数据库自身优化(大数据量)

数据库优化包含以下三部分,数据库自身的优化,数据库表优化,程序操作优化.此文为第一部分 数据库性能优化一:数据库自身优化 优化①:增加次数据文件,设置文件自动增长(粗略数据分区) 1.1:增加次数据文件 从SQL SERVER 2005开始,数据库不默认生成NDF数据文件,一般情况下有一个主数据文件(MDF)就够了,但是有些大型的数据库,由于信息很多,而且查询频繁,所以为了提高查询速度,可以把一些表或者一些表中的部分记录分开存储在不同的数据文件里由于CPU和内存的速度远大于硬盘的读写速度,所以可

玩转Oracle之12c 可插拔数据库数据泵功能体验

:数据泵可以高效备份.复制.保护和传输大量的数据和源数据.在导入和导出过程中可以做到过滤数据和对象,并且能够在全数据库级.方案级.表级和表空间级实现导入导出. Oracle12c的datapump功能跟以前差不多,在多租户的环境中执行导入\导出以及使用一些更细化的参数的时候,几乎没有区别,依然很好用,效率很高.目前有很多的用户仍然在使用exp/imp工具在执行一些迁移.备份.过滤和转移数据的工作,相比起来,数据泵的效率更高.更易用并且更方便管理,但exp/imp在有些时候可以完成datapump

分享工作中遇到的问题积累经验 事务日志太大导致insert不进数据

原文:分享工作中遇到的问题积累经验 事务日志太大导致insert不进数据 分享工作中遇到的问题积累经验 事务日志太大导致insert不进数据 今天开发找我,说数据库insert不进数据,叫我看一下 他发了一个截图给我 然后我登录上服务器,发现了可疑的地方,而且这个数据库之前有一段经历 在月初的时候这个数据库曾经置疑过,启动不起来 Could not redo log record (163041:116859:5), for transaction ID (0:-1175226963), on

数据库日志太大,清理日志文件

如果你的数据库出现如下场景,那么你需要对数据库进行日志清理了. 注:清理后的数据库,可能无法对数据库进行还原,所以,清理之前需要对数据库进行完整备份: 1.没有做任何操作,数据库日渐查询缓慢. 2.数据库数据很少,但是日志文件很大 你就需要查看是否日志文件过大,如果日志文件太大,就需要对日志文件进行清理了. 清理输入框的脚本如下: ----查询数据库日志 USE 数据库名 SELECT NAME, size FROM sys.database_files -----清空数据库日志 USE mas

大数据与数据库的区别,大数据的备份与恢复

大数据(big data),指无法在可承受的时间范围内用常规软件工具进行捕捉.管理和处理的数据集合,是需要新处理模式才能具有更强的决策力.洞察发现力和流程优化能力来适应海量.高增长率和多样化的信息资产. 数据库(Database)是按照数据结构来组织.存储和管理数据的仓库,它产生于距今六十多年前,随着信息技术和市场的发展,特别是二十世纪九十年代以后,数据管理不再仅仅是存储和管理数据,而转变成用户所需要的各种数据管理的方式.数据库有很多种类型,从最简单的存储有各种数据的表格到能够进行海量数据存储的