A事务里创新某个数据,出现这么的标题得以无庸

2019-07-17 作者:数据库   |   浏览(53)

 

通过were和having条件可以对数据进行筛选,那么如何通过排序对数据进行筛选呢?

引发思考

今天,发现开发项目中的单号重复了。

图片 1

这是多用户并发操作相同数据导致的结果。有点抽象,理解如下:实际就是多个事务交叉执行(增、删、查、改)了相同数据。导致一个事务不具有完整性了,数据库的数据也不一致了(这里‘’一致‘’可以理解为:我希望的数据,跟我想像的不一样,比如明明我刚update某表性别为男,我update完它还是女的,如果别人要修改,也得等我update完再改呀!咦,统计男生的总人数的确是加1了,见鬼了)。

图片 2

with cte as
(
select belongsAgent from [QPProxyDB].[dbo].[BS_ProxyInfo] where ProxyID = @ProxyID 
union all
select a.ProxyID from [QPProxyDB].[dbo].[BS_ProxyInfo] a join cte b on a.ProxyID = b.belongsAgent
)
select * from cte order by belongsAgent asc

错误提示:

消息 829,级别 21,状态 1,第 1 行
数据库 ID 15,页 (1:21826) 已标记为 RestorePending,可能表明磁盘已损坏。要从此状态恢复,请执行还原操作。

1.TOP筛选

并发操作数据的不利影响

多个用户试图修改其他用户正在使用的资源时总是会产生负面影响。(这里用户可以理解成事务,用户这个词组总是在不同场合出现,例如redis客户端用户,b/s模式客户端用户,这些情况其实可以广泛理解为请求)

更新丢失:A事务里更新某些数据,A还没结束运行。这段时间,B插足一脚,也更新了那些数据,覆盖了A刚更新完的,A白更了。一段时间后,A正常结束了,A丢失了更新的数据。

脏读:B正在修改某些数据,还没结束运行。这段时间A去读那些数据,但读的不是B修改之后的,而是B修改之前的。一段时间后,B正常结束了,A读的数据还是旧数据。

不可重复读:9点钟,A在读某部分数据。9点半,B修改了那部分数据,B结束运行了。10点钟,A又回头读那部分数据,发现数据和9点钟的不一样。A读的是同一部分,却返回不一样的数据。

 幻读:9点钟A根据条件取了一个结果集看看,还没结束运行。9点半,B删除了那个结果集部分行数据,又新增了部分行数据。10点,A根据相同条件取结果集,发现新增了部分,删除了部分,刚刚是在做梦吧?

总而言之,一旦小三插足干坏事,我就完了。

 

引起原因:

RestorePending一般是在进行页恢复的过程中出现的,就是在进行了restore操作之后但还没有进行recovery操作之前页的状态。

出现这样的问题可以肯定这个表是损坏了,但是在查询数据的时候如果不会查询到损坏页面的数据话是不会报错的,也就是说可以有条件的使用这个表。

如果损坏的页只有一个的话,那删除掉这个坏表故障肯定就没有了,因为一个页里面只会放一个表的数据。

损坏的直接原因就是放在磁盘上面的数据被意外的修改了或者写入的时候出错这些,可能是磁盘问题,但是IO系统可能性更大。

可以好好的检查系统日志和SQLServer的LOG,看看里面有没有关于磁盘或者IO之类的警告、报错信息,以进一步确定原因。

至于处理方法,如果表重要那就利用备份做页面还原恢复数据,不重要的话就删掉重建,

或者使用以下方式进行修复,在处理完坏页之后再对整个数据库做一次DBCC CHECKDB操作,确保没有其他的坏页。

用于限制查询返回行数或者行数的百分比。

事务锁

针对上面的问题,可以使用事务锁解决。(事务锁是一种悲观的解决方案,)

每个事务里可能涉及行数据、页数据、表数据、,这数据相等事务依赖的资源,当请求操作这些资源,可以请求不同类型的锁。 该锁可以阻止其他事务以错误方式操作该资源。 当事务不再依赖锁定的资源时,它将释放锁。

简单说,这些数据可以被上锁、上锁后,其他事务对该数据的操做就有限制了,不是你想改就能改,你想读就读。我锁是大爷,我允许,你就能操作;我若不许,你就滚出去!

 

锁粒度: SQL Server具有多种粒度锁定,例如行粒度、表粒度、数据库粒度......

如果在较小的粒度(例如行)加锁,可以提高并发度,因为对其他事务限制范围小,只是开销较高,锁定了多少行,则需要多少锁。

比如A事务拿到了某行数据的某锁,该限制了其他事务对该行数据的操作,但是其他事务不一定要操作该行,也是就1两个事务需要操作改行,

如果在较大的粒度(例如表)加锁,则会降低并发度,因为锁定整个表限制了其他事务对表中任意部分的访问。 但开销较低,因为需要维护的锁较少。

 

锁类型:共享锁、排他锁等。锁与锁之间是可以冲突的。比如A事务拿到了某行数据的共享锁,说明A事务结束之前,该行数据都不能被其他事务修改(增、删、改),但是其他事务可以读改行数据。其他事务永远都不能拿到该行数据的排他锁,排他锁的作用是独自占据数据的增、删、改操作。

 

这篇文章不过抛转引玉罢了,官方的就很齐全了

 

ProxyID 父级

belongsAgent 子集

解决办法:

快速修复
DBCC CHECKDB ('数据库名', REPAIR_FAST) 

重建索引并修复
DBCC CHECKDB ('数据库名', REPAIR_REBUILD)

如果必要允许丢失数据修复
DBCC CHECKDB ('数据库名'', REPAIR_ALLOW_DATA_LOSS)

例如 我们对订单表筛选最近产生的订单5条

 


SELECT TOP (5) orderid, orderdate, custid, empid
FROM Sales.Orders
ORDER BY orderdate DESC;

 

这是通过 排序对数据进行筛选

本文由小鱼儿玄机30码发布于数据库,转载请注明出处:A事务里创新某个数据,出现这么的标题得以无庸

关键词: 小鱼儿玄机30码