由于一次不谨慎的变更，没有注意standby数据库文件系统的空间，在增加表空间数据文件的时候，standby没有足够的空间，导致了recovery是吧。
处理过程
先shutdown standby数据库
由于主备之间的数据文件已经不相同了，准备在备库上添加数据问题
1.首先备份pfile 然后修改参数standby_file_management=manual
2.startup nomount；alter database mount standby database;
3.alter database open read only;这步的时候失败，保数据文件#37有错，需要做recovery (注:#37为本次standby由于空间不够失败的第一个数据文件)
4.尝试做recovery 同样报错，分析，由于数据文件#37有问题，所以archive 没办法继续下去，所以先吧#37数据文件offline drop掉，再做recovery就报#38文件有错，同样offline drop掉，一直到把变更中失败的几个都offline drop以后，可以正常的apply archive log了。一直到最近一个归档日志都apply后
5.然后扩文件系统空间，把缺少的数据文件补上去，
alter database create datafile 'AAAAA’ as 'BBBBB';
AAAA对应的是v$datafile中#37的file
BBBB为实际添加的数据文件
这样依次把失败的数据文件补全。
最后恢复主备机的同步
6.alter database recover managed standby database disconnect from session;
主机切换日志文件后 查看主备机直接的同步正常。
现存的问题就是把 standby_file_management 改回auto后 主机上更改这几个数据文件，这个不会同步，同时主备直接的同步就会停住，只能先把该参数改成manual，再找可以停主数据库的变更时间 再说了。
处理过程
先shutdown standby数据库
由于主备之间的数据文件已经不相同了，准备在备库上添加数据问题
1.首先备份pfile 然后修改参数standby_file_management=manual
2.startup nomount；alter database mount standby database;
3.alter database open read only;这步的时候失败，保数据文件#37有错，需要做recovery (注:#37为本次standby由于空间不够失败的第一个数据文件)
4.尝试做recovery 同样报错，分析，由于数据文件#37有问题，所以archive 没办法继续下去，所以先吧#37数据文件offline drop掉，再做recovery就报#38文件有错，同样offline drop掉，一直到把变更中失败的几个都offline drop以后，可以正常的apply archive log了。一直到最近一个归档日志都apply后
5.然后扩文件系统空间，把缺少的数据文件补上去，
alter database create datafile 'AAAAA’ as 'BBBBB';
AAAA对应的是v$datafile中#37的file
BBBB为实际添加的数据文件
这样依次把失败的数据文件补全。
最后恢复主备机的同步
6.alter database recover managed standby database disconnect from session;
主机切换日志文件后 查看主备机直接的同步正常。
现存的问题就是把 standby_file_management 改回auto后 主机上更改这几个数据文件，这个不会同步，同时主备直接的同步就会停住，只能先把该参数改成manual，再找可以停主数据库的变更时间 再说了。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/2361091/viewspace-624037/ ，如需转载，请注明出处，否则将追究法律责任。
请登录后发表评论
登录
全部评论
