急急急~!!!附加数据库慢的问题

2013-09-26 11:14:50
一个MDF 文件80G,加一个log文件是64G。。。正在附加

之前是有由于我强行关闭了SQL 服务,重新打开的时候说恢复文件。然后找CSDN 的方法附加数据库。
现在心急如焚。。。

附加数据库的上面一直在提示“正在执行”,我也不知道多久~~现在还有什么好方法? 的要等多久呢?
...全文
921 17 打赏 收藏 转发到动态 举报
写回复
用AI写文章
17 条回复
切换为时间正序
请发表友善的回复…
发表回复
發糞塗牆 2013-09-26
  • 打赏
  • 举报
回复
减少对服务器的操作.....然后等吧
2013-09-26
  • 打赏
  • 举报
回复
引用 10 楼 DBA_Huangzj 的回复:
那问题很可能在回滚事务,因为你强行关闭,所以事务需要回滚,回滚常规来说是:运行多久回滚多久。这个你控制不了的。我上次也试过强行关闭一个运行了1小时的操作,结果等恢复等了2小时。
我晕。。我运行了12个小时。。。杯具了 ~~~~那不要等两天 ~~
發糞塗牆 2013-09-26
  • 打赏
  • 举报
回复
那问题很可能在回滚事务,因为你强行关闭,所以事务需要回滚,回滚常规来说是:运行多久回滚多久。这个你控制不了的。我上次也试过强行关闭一个运行了1小时的操作,结果等恢复等了2小时。
2013-09-26
  • 打赏
  • 举报
回复
引用 8 楼 DBA_Huangzj 的回复:
没有数据应该是没有阻塞,也就是慢是慢在附加的过程中。你服务器如果不是重启过,那内存满很正常啊。任何关系型数据库都吃内存,其他的我就不敢说。IO问题除非你有准确的数据证明“没有问题”,不然没有所谓的应该。如果没有阻塞,那就等吧。
服务器IO 应该没什么问题啊, 我之前用剪切的形式把两个文件切出去了 ~~ 初始化怎么会那么慢呢 ?我记得附加数据库应该是很快的啊 ~~~ 还有我在7 楼说的问题,这个跟那应该有关系吧。
發糞塗牆 2013-09-26
  • 打赏
  • 举报
回复
没有数据应该是没有阻塞,也就是慢是慢在附加的过程中。你服务器如果不是重启过,那内存满很正常啊。任何关系型数据库都吃内存,其他的我就不敢说。IO问题除非你有准确的数据证明“没有问题”,不然没有所谓的应该。如果没有阻塞,那就等吧。
2013-09-26
  • 打赏
  • 举报
回复
还有一个问题,是这个数据在我之前关闭服务之前,进行一个大批量的数据插入,但是那个作业执行了大概12个小时依旧现在正在执行,我就把SQL 服务给关掉了,然后就在打开就显示“正在恢复”。我就再关闭服务,然后剪切出去,在附加数据库的方法,就到现在了现在的情况
2013-09-26
  • 打赏
  • 举报
回复
查询没有任何数据 但是为什么内存是满的呢? IO 的问题,应该不会那么慢啊 ~~~欲哭无泪啊 ~~现在~~
發糞塗牆 2013-09-26
  • 打赏
  • 举报
回复
附加是IO问题,和内存CPU一般没多大关系,附加要初始化的,如果你没有“即使文件初始化”的权限,那会很慢,你可以到sqlserver查查:select * from sys.sysprocesses where blocked<>0有没有数据。回复请引用
2013-09-26
  • 打赏
  • 举报
回复
内存一直是慢的,但CPU 好低~~~感觉好像没有在附加一样,我记得附加应该是很快的啊 ~~
發糞塗牆 2013-09-26
  • 打赏
  • 举报
回复
你只能等待了,不然很可能出问题
2013-09-26
  • 打赏
  • 举报
回复
回LS 那个时候有恢复的过程,但我终止了,现在是附加数据库。。时间不知道要多久啊 ~~真急~!!
發糞塗牆 2013-09-26
  • 打赏
  • 举报
回复
这里有个大概值,但是仅仅是大概,你的问题应该是IO太慢,或者当时分离时强行分离,很多事务没有提交,现在需要回滚
DECLARE @DBName VARCHAR(64) = 'DB_Name'
 
DECLARE @ErrorLog AS TABLE([LogDate] CHAR(24), [ProcessInfo] VARCHAR(64), [TEXT] VARCHAR(MAX))
 
INSERT INTO @ErrorLog
EXEC sys.xp_readerrorlog 0, 1, 'Recovery of database', @DBName
 
SELECT TOP 10
	 [LogDate]
	,SUBSTRING([TEXT], CHARINDEX(') is ', [TEXT]) + 4,CHARINDEX(' complete (', [TEXT]) - CHARINDEX(') is ', [TEXT]) - 4) AS PercentComplete
	,CAST(SUBSTRING([TEXT], CHARINDEX('approximately', [TEXT]) + 13,CHARINDEX(' seconds remain', [TEXT]) - CHARINDEX('approximately', [TEXT]) - 13) AS FLOAT)/60.0 AS MinutesRemaining
	,CAST(SUBSTRING([TEXT], CHARINDEX('approximately', [TEXT]) + 13,CHARINDEX(' seconds remain', [TEXT]) - CHARINDEX('approximately', [TEXT]) - 13) AS FLOAT)/60.0/60.0 AS HoursRemaining
	,[TEXT]
 

FROM @ErrorLog ORDER BY [LogDate] DESC
Q315054403 2013-09-26
  • 打赏
  • 举报
回复
啥任务能执行12个小时? 把80G数据翻江倒海地折腾,也最多二三十分钟。一定是设计问题,该改进
lin3360827 2013-09-26
  • 打赏
  • 举报
回复
慢慢恢复吧,我这边数据库和你一样大小 我下午下班前恢复.BAK 次日来就好了。 别动它别管他
guguda2008 2013-09-26
  • 打赏
  • 举报
回复
强行关闭?正在恢复? 等着吧哈哈哈哈,我有次等了一下午呢
發糞塗牆 2013-09-26
  • 打赏
  • 举报
回复
下次不要随便干预这些操作了,特别是服务器级别的
2013-09-26
  • 打赏
  • 举报
回复
引用 12 楼 DBA_Huangzj 的回复:
减少对服务器的操作.....然后等吧
恢复了3个小时成功了,估计12个小时里面前面都是查询,只有3个小时才是插入操作,煎熬3个小时啊,终于恢复成功,着实把我吓一跳。

34,872

社区成员

发帖
与我相关
我的任务
社区描述
MS-SQL Server相关内容讨论专区
社区管理员
  • 基础类社区
  • 二月十六
  • 卖水果的net
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧