由 DB_FILES 参数导致的 dg 服务器无法同步问题

由 DB_FILES 参数导致的 dg 服务器无法同步问题

用户反映,dg 服务器数据从昨晚(7月8日)开始停止同步。

连接服务器发现没有 mrp 进程,并且 OPEN_MODE 参数也不正确。具体情况如下所示:

sql 复制代码
SQL> select process, status, sequence# from v$managed_standby;

PROCESS   STATUS	SEQUENCE#
--------- ------------ ----------
ARCH	  CLOSING	  1356467
ARCH	  CONNECTED		0
ARCH	  CONNECTED		0
ARCH	  CLOSING	  2317672
RFS	  IDLE			0
RFS	  IDLE			0
RFS	  IDLE		  2317673
RFS	  IDLE		  1356468
RFS	  IDLE			0
RFS	  IDLE			0

10 rows selected.

SQL> select open_mode,log_mode, database_role from v$database;

OPEN_MODE	     LOG_MODE	         DATABASE_ROLE
-------------------- ------------ -------------------- ----------------
READ ONLY	     ARCHIVELOG        PHYSICAL STANDBY

执行如下命令出现异常(ORA-00059):

sql 复制代码
SQL> alter database recover managed standby database;
alter database recover managed standby database
*
ERROR at line 1:
ORA-00283: recovery session canceled due to errors
ORA-00059: maximum number of DB_FILES exceeded

提示是 DB_FILES 参数的问题。并且昨晚对服务器进行扩容,为多个表空间增加了数据文件。dg 数据库停止同步也是昨天晚上。确认是该参数的问题。

以前已经修改过主库的 DB_FILES 参数为 2000,备库的 DB_FILES 参数为默认值 200。

确定问题的解决方案为,修改 DB_FILES 参数的值为 2000,步骤如下:

步骤一:执行如下命令修改 DB_FILES 参数的值。

sql 复制代码
alter system set db_files=2000 scope=spfile;

步骤二:重启数据库。

sql 复制代码
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.

Total System Global Area 3.4206E+10 bytes
Fixed Size		    2270360 bytes
Variable Size		 5301603176 bytes
Database Buffers	 2.8857E+10 bytes
Redo Buffers		   45649920 bytes
Database mounted.
Database opened.

步骤三:执行如下命令开启同步。

sql 复制代码
SQL> alter database recover managed standby database using current logfile disconnect;

Database altered.

步骤四:查看 dg 备库的进程及数据库状态。

sql 复制代码
SQL> select process, status, sequence# from v$managed_standby;

PROCESS   STATUS	SEQUENCE#
--------- ------------ ----------
ARCH	  CLOSING	  1356468
ARCH	  CONNECTED		0
ARCH	  CONNECTED		0
ARCH	  CLOSING	  2317673
RFS	  IDLE			0
RFS	  IDLE			0
RFS	  IDLE		  2317674
RFS	  IDLE		  1356469
RFS	  IDLE			0
RFS	  IDLE			0
MRP0	  APPLYING_LOG	  1356458

11 rows selected.


SQL> select open_mode,log_mode,database_role from v$database;

OPEN_MODE	     LOG_MODE	      DATABASE_ROLE
-------------------- ------------ -------------------- ----------------
READ ONLY WITH APPLY ARCHIVELOG    PHYSICAL STANDBY

发现备库的进程以及状态已经恢复正常。

测试数据的同步情况,发现已经恢复。

相关推荐
齐齐大魔王5 小时前
linux-僵死进程处理
linux·运维·服务器
HackTwoHub7 小时前
AI大模型网关存在SQL注入、附 POC 复现、影响版本LiteLLM 1.81.16~1.83.7(CVE-2026-42208)
数据库·人工智能·sql·网络安全·系统安全·网络攻击模型·安全架构
l1t8 小时前
DeepSeek总结的DuckLake构建基于 SQL 原生表格式的下一代数据湖仓
数据库·sql
KmSH8umpK8 小时前
Redis分布式锁从原生手写到Redisson高阶落地,附线上死锁复盘优化方案进阶第八篇
数据库·redis·分布式
.小小陈.8 小时前
Linux 线程概念与控制:从底层原理到实战应用
linux·运维·jvm
网络工程小王8 小时前
【LangChain 大模型6大调用指南】调用大模型篇
linux·运维·服务器·人工智能·学习
TDengine (老段)8 小时前
从施工监测到运营预警,桥科院用 TDengine 提升桥梁数据管理能力
大数据·数据库·物联网·时序数据库·tdengine·涛思数据
wangbing11258 小时前
各linux版本的包管理命令
linux·运维·服务器
Joseph Cooper9 小时前
Linux/Android 跟踪技术:ftrace、TRACE_EVENT、atrace、systrace 与 perfetto 入门
android·linux·运维
S1998_1997111609•X9 小时前
论mysql国盾shell-sfa犯罪行为集团下的分项工程及反向注入原理尐深度纳米算法下的鐌檵鄐鉎行为
网络·数据库·网络协议·百度·开闭原则