z***y
发帖数: 7151 | 1 上个月的事情。故事的发生是这样滴。。。
有一个update 转了七个小时了， 因为巨大的更新， 结果数据库log went of disk
space。 卡在那里了， 而且还把别的sesssion 挡住。 同一张硬盘上已经找不到空间
了。
应用程序每天6：00AM 上线， 现在还有1个小时， 这台server 别的disk 有足够的空
间。
现在问题来了： 整个blocking chain ， 就是这个Update 源头。 但是回退1个小时之
内是做不完滴。 客户说了， update 马上还有十来分钟就能全做完。
你得马上拿出方案来。 |
a9
发帖数: 21638 | 2 没空间了应该是直接就停了吧？
【在 z***y 的大作中提到】
: 上个月的事情。故事的发生是这样滴。。。
: 有一个update 转了七个小时了， 因为巨大的更新， 结果数据库log went of disk
: space。 卡在那里了， 而且还把别的sesssion 挡住。 同一张硬盘上已经找不到空间
: 了。
: 应用程序每天6：00AM 上线， 现在还有1个小时， 这台server 别的disk 有足够的空
: 间。
: 现在问题来了： 整个blocking chain ， 就是这个Update 源头。 但是回退1个小时之
: 内是做不完滴。 客户说了， update 马上还有十来分钟就能全做完。
: 你得马上拿出方案来。
|
z***y
发帖数: 7151 | 3 不能停。
版上很多的问题是关于如何开发的， 其实 DBA 做的更多的工作是这一类的
Maintenance & Run.
【在 a9 的大作中提到】
: 没空间了应该是直接就停了吧？
|
z***y
发帖数: 7151 | 4 我来说说解决方案吧：
这个时候， 绝对不能kill update session， roll back will take more than hours
.
加上一个log file， 等update 完成。 然后做log backup。做两遍。 然后把
original log file shrink 然后再把这个log file 的所有entry 搬到original log
file, 最后 把加上的这个log file 去掉。
35分钟全部搞定。
【在 z***y 的大作中提到】
: 上个月的事情。故事的发生是这样滴。。。
: 有一个update 转了七个小时了， 因为巨大的更新， 结果数据库log went of disk
: space。 卡在那里了， 而且还把别的sesssion 挡住。 同一张硬盘上已经找不到空间
: 了。
: 应用程序每天6：00AM 上线， 现在还有1个小时， 这台server 别的disk 有足够的空
: 间。
: 现在问题来了： 整个blocking chain ， 就是这个Update 源头。 但是回退1个小时之
: 内是做不完滴。 客户说了， update 马上还有十来分钟就能全做完。
: 你得马上拿出方案来。
|
B*****g
发帖数: 34098 | 5 mark
hours
log
【在 z***y 的大作中提到】
: 我来说说解决方案吧：
: 这个时候， 绝对不能kill update session， roll back will take more than hours
: .
: 加上一个log file， 等update 完成。 然后做log backup。做两遍。 然后把
: original log file shrink 然后再把这个log file 的所有entry 搬到original log
: file, 最后 把加上的这个log file 去掉。
: 35分钟全部搞定。
|
s**********o
发帖数: 14359 | 6 你个DBA怎么会让人UPDATE这么久，不怕把TABLE全都BLOCK掉吗？
有些公司的劣质BATCH JOB经常要RUN5个小时以上，如果
白天RUN，公司基本上在找死。要么分成小块的UPDATE，
如果是定期的就要考虑ETL SSIS了。 |
a9
发帖数: 21638 | 7 我的意思是，我记得如果遇到空间不足，还原过程会直接报错中止的啊。
我原来空间不足的做法是直接进行日志备份，然后收缩日志。
【在 z***y 的大作中提到】
: 不能停。
: 版上很多的问题是关于如何开发的， 其实 DBA 做的更多的工作是这一类的
: Maintenance & Run.
|
s**********o
发帖数: 14359 | 8 谁RUN这个UPDATE JOB谁要被批评，这么多数据UPDATE当然会OUT OF SPACE，为什么没
有提前通知DBA呢，还是DBA没估计到这么大的UPDATE呢。我以前工作的公司，有个
DEVELOPER RUN了大批量的UPDATE的JOB, 把SERVER搞当了，ORDER也搞坏了，结果被开
除了。 |
z***y
发帖数: 7151 | 9 如果update 过程不完成， 会提示说log file is being used. 你如果查 log_reuse_
wait_desc, 如果值不是“nothing” 你是没有办法shrink file.
【在 a9 的大作中提到】
: 我的意思是，我记得如果遇到空间不足，还原过程会直接报错中止的啊。
: 我原来空间不足的做法是直接进行日志备份，然后收缩日志。
|
z***y
发帖数: 7151 | 10 呵呵。 多谢指教。
【在 s**********o 的大作中提到】
: 你个DBA怎么会让人UPDATE这么久，不怕把TABLE全都BLOCK掉吗？
: 有些公司的劣质BATCH JOB经常要RUN5个小时以上，如果
: 白天RUN，公司基本上在找死。要么分成小块的UPDATE，
: 如果是定期的就要考虑ETL SSIS了。
|
i****a
发帖数: 36252 | 11 create 2nd log file on another disk?
【在 z***y 的大作中提到】
: 上个月的事情。故事的发生是这样滴。。。
: 有一个update 转了七个小时了， 因为巨大的更新， 结果数据库log went of disk
: space。 卡在那里了， 而且还把别的sesssion 挡住。 同一张硬盘上已经找不到空间
: 了。
: 应用程序每天6：00AM 上线， 现在还有1个小时， 这台server 别的disk 有足够的空
: 间。
: 现在问题来了： 整个blocking chain ， 就是这个Update 源头。 但是回退1个小时之
: 内是做不完滴。 客户说了， update 马上还有十来分钟就能全做完。
: 你得马上拿出方案来。
|
s**********o
发帖数: 14359 | 12 一般都是这样的，让那个UPDATE JOB弄完，然后BACKUP LOG，再DROP 2ND LOG
【在 i****a 的大作中提到】
: create 2nd log file on another disk?
|
d**********3
发帖数: 1186 | 13 set rowcount =200
Loop begin
update ..
where PK between
loop end |
