详细版本信息：--03134284044-20230615-193278-20040 Pack11 1-3-12-2023.06.15-193278-20040-ENT

访问：dba_segments，也会触发宕机

在操作前，强烈建议先对当前库作全库冷备，并将备份集做妥善的保存（dm.ini、dmarch.ini啥的也都存好），另外，如果要测试，也建议单独搭建一个独立的环境来进行。
目前现场务必保存好，这样后面有了对策才便于处理，也能尽量避免引入额外的数据丢失风险。

先确认一下，这个跟之前page(5,0,16)坏了那次是同一个库么？之前坏页处理后，有没有作全库的dmdbchk？
如果上次已经作过全库的dmdbchk，这次是新出现的坏页，那建议原环境不要再折腾了，启个新实例去处理吧。

同时，从上次库中出现坏块到现在发现这个page(5,0,2817)之间的这段时间里，库中是否还在跑业务？也就是库中其他表数据是否有变动？

如果库中数据从上次迄今未有作变动
单独创建一个实例，在其中将上次备份数据灌入，并用dexp备份，将已知存在坏页的表作排除
dexp备份完成后，再建立一个新实例作过渡库，用dimp导入
导入完成后，停实例，并使用dmdbchk作全库检查，以确认是否还存在其他坏页情况。

如果库中数据已有变动
对当前库作冷备后，单独创建一个实例作为数据修复环境，使用冷备数据恢复库。
然后跟上面一样，用dexp备份，并排除掉已知存在坏页的表
备份后，再启一个过渡用的实例，建库、建用户、dimp导入数据，然后停实例，再dmdbchk检查

在过渡库中已确认修复，且dmdbchk通过后，对新模式内对象（视图、存储过程、包、触发器什么的）的有效性进行核对，并对失效对象及时进行重建或修正，以确保该库的状态已符合上线标准。

带过渡库已完成上线准备后
可以考虑将过渡库中模式备份并恢复到生产环境。
或者，将原生产库停机隔离，先用过渡库作生产库。

我个人建议采用后者，保存的原环境（当黑匣子了）可以后面请达梦的专家来分析引发坏块的原因，避免后面再次出现新坏块。

还是上次那话，强烈建议，千万别嫌备份、创建新实例什么的浪费时间和空间，毕竟小心才能驶得万年船。