在DG日常维护的时候,很可能会发生的情况是:
1. 主库端扩容了某个表空间,增加了数据文件
2. 备库端同步增加了该数据文件,结果导致了挂载点的空间紧张

对于这种情况,比较好的做法是:
正确配置convert参数。
注意:对convert参数的修改需要特别注意,否则后面会讲到一个关于数据文件的异常(后面篇幅中将会提到)。

但是如果你没有很好的配置convert参数,导致空间紧张的情况发生了,并且,更糟糕的是:
当前空间紧张的挂载点是没有启用逻辑卷的(Linux中)

因此,为了防止空间撑爆,你会需要做出如下修复。

————————————————————
1. 停掉数据恢复
alter database recover managed standby database cancel

2. 将数据库置于mount阶段
查看:
select instance_name,status from v$instance;
select name,database_role from v$database

如果当前已经是MOUNT阶段就不用修改。
否则重启数据库到mount阶段
shutdown immediate;
startup mount

3. 查看当前数据库数据文件
set linesize 400;
set pagesize 300;
col name for a60;
select file#,ts#,status,name,bytes/1024/1024 “MB”,to_char(creation_time,’yyyy-mm-dd hh24:mi:ss’) “Create Time”,to_char(last_time,’yyyy-mm-dd hh24:mi:ss’) “Last Time” from v$datafile order by file#;

在这里,你需要注意这几点:
— 1) 找到你要修改位置的数据文件,确认当前位置,以及你要移动到的位置
— 2) 看看上面的数据文件的状态是否正常

4. 文件系统中,将目标文件,源文件移动到目标位置:
cp xxx_orig xxx_dest

5. 数据库,修改参数:
alter system set standby_file_management=manual;

6. 数据文件修改数据文件路径:
eg:
alter database rename file ‘/ssd/data3/oracle/oradata/yhddb1/system.dbf’ to ‘/data3/oracle/oradata/yhddb1/system.dbf’;

7. 还原参数:
alter system set standby_file_management=auto;

8. 恢复DG数据恢复
alter database recover managed standby database disconnect from session;

这样,就解决了。

————————————————————————————————————
上面过程中,你可能遇到的问题:

一:convert参数与数据文件状态

在我的环境里,这个状态有点问题:

可以看到,其中有几个数据文件的MB是【0】
这就是因为修改convert参数的时候没有注意导致的。(修复方式就是移动数据文件路径,后面会提到)

之前:Convert的配置:

之前:数据文件状态:

现在(正确以后):convert的配置

现在(正确以后):数据文件

二、数据库中的数据文件位置不是真实的数据文件位置会导致DG数据恢复进程启动报错

日志如下:

————————————————
Done。

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

隐藏
变装