达梦数据库数据文件损坏排查与处理方法

本文详细介绍了数据库无法启动或自动停止的问题排查步骤,包括检查系统资源、数据文件完整性校验、数据库恢复方法。提供了两种恢复策略:新库初始化和数据迁移,适用于不同情况下的数据库故障修复。
部署运行你感兴趣的模型镜像

故障排查:

数据库无法启动,或者启动一段之间自动停止

具体现象要具体分析

1.判断系统因素

首先要确定内存空间和存储空间是否满了导致无法启动

查看内存命令:free  -m

查看存储命令:df  -h

 

如果查询结果都是未满的,要具体分析日志考虑是否为数据文件损坏。

  1. 对数据文件完整性进行校验

先停掉数据库外部连接,复制一份当前的数据文件到其他路径下留作备份,注意其他路径下空间大小是否充足。

cp  /opt/dmdbms/data/DAMENG  /home/DAMENG_OLD_BAK1

修改/opt/dmdbms/data/DAMENG/dm.ini中port_num(端口号)为5237(不和其他数据库端口冲突)

保证不会有外部因素影响。

前台启动数据库

cd  /opt/dmdbms/bin/

./dmserver  /opt/dmdbms/data/DAMENG/dm.ini

终端打印出system  is  ready后输入exit停止数据库

在相同路径下执行

./dmdbchk  PATH=/opt/dmdbms/data/DAMENG/dm.ini

检查文件是否有报错

如果损坏,先将当前数据文件文件夹复制一份到其他位置保存,以便有一个最原始的存档。

有备份的情况下,可以基于备份还原。

无备份的情况下,可以尝试通过以下几种方式恢复。

记得将之前修改/opt/dmdbms/data/DAMENG/dm.ini中port_num(端口号)为5237改回5236。

恢复数据库方法:

数据库宕机后,此时服务停止,需要做以下操作尝试启动数据库服务

注意不要有任何应用连接数据库,以下方法均基于最初损坏时环境来进行操作,请不要直接将方法一和方法二连续使用,防止操作导致复制出的文件夹过多使人记忆混乱,操作失误

方法一:

1。确认服务状态 ,停服务

关于文件夹的操作,请注意是哪个路径下的文件夹

2。先复制一份当前的数据文件到其他路径下留作备份

cp  /opt/dmdbms/data/DAMENG  /home/DAMENG_OLD_BAK1

复制请注意其他路径下空间大小是否充足。

3。将当前(旧)数据库文件目录重命名

mv  /opt/dmdbms/data/DAMENG  /opt/dmdbms/data/DAMENG_OLD_BAK

(当前路径/opt/dmdbms/data/下应该只有DAMENG_OLD_BAK文件夹)

4。查看初始化参数

/opt/dmdbms/data/DAMENG_OLD_BAK文件夹中dminit+时间.log

5。打开终端,初始化一个新库,所有参数与之前库相同

cd  /opt/dmdbms/bin/

./dminit path=/opt/dmdbms/data/ UNICODE_FLAG=1 CASE_SENSITIVE=0 EXTENT_SIZE=16 PAGE_SIZE=8 (后接参数视现场情况而定)

此时生成的DAMENG文件夹为新库的文件夹

(当前路径/opt/dmdbms/data/下应该有DAMENG(新库).DAMENG_OLD_BAK(旧库)两个文件夹)

6。初始化库完成后,启动新库服务一次:

./dmserver  /opt/dmdbms/data/DAMENG/dm.ini

终端打印出system  is  ready后输入exit或按ctrl+c停止服务

 

7。拷贝出新库的ROLL.DBF文件,移走所有新库数据文件

cp  -r  opt/dmdbms/data/DAMENG/ROLL.DBF  /opt/dmdbms/data/

mv  /opt/dmdbms/data/DAMENG  /opt/dmdbms/data/DAMENG_NEW_BAK

(当前路径/opt/dmdbms/data/下应该有DAMENG_NEW_BAK(新库)和DAMENG_OLD_BAK(旧库)两个文件夹)

8。复制一份旧库数据文件,命名为之前的名称

cp  -r  /opt/dmdbms/data/DAMENG_OLD_BAK  /opt/dmdbms/data/DAMENG

将刚刚新库拿出来的ROLL.DBF替换到旧库复制出来的文件夹中

mv  /opt/dmdbms/data/DAMENG/ROLL.DBF  /opt/dmdbms/data/DAMENG/ROLL_BAK.DBF

cp  /opt/dmdbms/data/ROLL.DBF  /opt/dmdbms/data/DAMENG/ROLL.DBF

(当前路径下应该有DAMENG_NEW_BAK(新库).DAMENG_OLD_BAK(旧库)DAMENG(旧库复制过来的) 三个文件夹)

9。尝试启动已宕机的数据库:打开终端,cd进入/opt/dmdbms/bin目录下,执行以下命令启动宕机数据库:./dmserver /opt/dmdbms/data/DAMENG/dm.ini

如服务启动成功,应用访问正常,则数据库恢复成功。

此方法如果无法恢复数据库正常提供服务,请使用以下方法尝试

方法二:

1。确认服务状态 ,停服务

关于文件夹的操作,请注意是哪个路径下的文件夹

2。先复制一份当前的数据文件到其他路径下留作备份

cp  /opt/dmdbms/data/DAMENG  /home/DAMENG_OLD_BAK1

复制请注意其他路径下空间大小是否充足。

3.。查看初始化参数

/opt/dmdbms/data/DAMENG文件夹中dminit+时间.log

(当前路径/opt/dmdbms/data/下应该只有DAMENG文件夹)

4。打开终端,初始化一个新库,所有参数与之前库相同

cd  /opt/dmdbms/bin/

./dminit path=/opt/dmdbms/data/ DB_NAME=DAMENG2 PORT_NUM=5237 UNICODE_FLAG=1 CASE_SENSITIVE=0 EXTENT_SIZE=16 PAGE_SIZE=8 (后接参数视现场情况而定)

此时生成的DAMENG1文件夹为新库的文件夹

(当前路径/opt/dmdbms/data/下应该有DAMENG1(新库),DAMENG(旧库)两个文件夹)

5。首先前台启动旧数据库

cd  /opt/dmdbms/bin/

./dmserver  /opt/dmdbms/data/DAMENG/dm.ini(此窗口不要关闭,关闭数据库也会停止)

6。新打开窗口,前台启动新数据库

cd  /opt/dmdbms/bin/

./dmserver  /opt/dmdbms/data/DAMENG1/dm.ini(此窗口不要关闭,关闭数据库也会停止)

以上两个窗口不要关闭

7。打开达梦迁移工具(dts)

新打开一个窗口

cd  /opt/dmdbms/tool/

./dts

此时会启动达梦迁移工具

使用迁移工具将旧数据库数据迁移到新数据库中,期间会遇到数据文件损坏的表,然后会导致旧数据库再次宕机,此时需要记录是哪张表导致的,然后重新打开旧数据库,再次迁移,此次将上次导致迁移失败的表取消勾选,然后迁移,尽可能将表都迁过去,如有报错,依次跳过报错表,最后总结报错表,将表结构,数据导出为SQL语句。在新库中通过sql语句创建,尝试修复。

您可能感兴趣的与本文相关的镜像

Llama Factory

Llama Factory

模型微调
LLama-Factory

LLaMA Factory 是一个简单易用且高效的大型语言模型(Large Language Model)训练与微调平台。通过 LLaMA Factory,可以在无需编写任何代码的前提下,在本地完成上百种预训练模型的微调

排查达梦数据库崩溃及启动失败的问题,通常需要从多个维度进行分析,包括数据库运行日志、错误日志、操作系统日志、内存配置、检查点机制以及 SQL 日志等。以下是详细的排查方法和解决思路: ### 数据库崩溃排查 1. **查看数据库运行日志** 数据库的运行日志通常记录了数据库的启动、运行及关闭过程中的相关信息。如果数据库崩溃,但运行日志中没有明显错误信息,可能表明崩溃发生在较低层,如操作系统或内存层面。 - 检查 `dmserver` 的运行日志路径,确认日志文件是否完整且未被截断。 - 查看日志中最近一次数据库启动和关闭的时间点,判断是否为异常关闭。 2. **查看数据库错误日志** 错误日志记录了数据库运行过程中发生的错误信息,是排查数据库崩溃的重要依据。 - 检查 `dmserver` 的错误日志,确认是否存在崩溃相关的错误信息。 - 如果错误日志为空,可能需要进一步查看操作系统日志。 3. **查看操作系统日志** 在 Linux 系统中,可以通过 `/var/log/messages` 或 `/var/log/syslog` 查看系统级日志,特别是 `dmserver` 相关的条目。 - 使用 `grep dmserver /var/log/messages` 命令过滤达梦数据库相关的日志。 - 如果发现 `OOM`(Out of Memory)错误,说明数据库可能因内存不足而被系统强制终止。此时应检查 `dm.ini` 文件中的内存配置,特别是 `BUFFER` 参数设置是否合理。 4. **检查数据库配置文件 `dm.ini`** `dm.ini` 是达梦数据库的核心配置文件,包含数据库的内存、连接、日志等参数。 - 检查 `BUFFER` 配置项,确保其值足够支持当前的数据库负载。 - 确认是否执行过数据库优化脚本,如未执行,可能导致性能问题或内存不足。 5. **检查点机制验证** 检查点机制在数据库崩溃恢复中起着关键作用,它确保缓冲区中的脏数据被写入磁盘。 - 检查数据库崩溃后是否自动触发了检查点。 - 确保数据库启动时能够正确恢复未完成的事务,并验证日志文件是否被正确重用。 - 手动执行 `CHECKPOINT()` 函数,强制触发检查点,观察系统行为。 6. **使用 SQL 日志分析工具 `Dmlog`** `Dmlog` 是达梦数据库提供的 SQL 日志分析工具,可用于分析数据库操作日志。 - 确保日志文件格式符合要求,每条 SQL 语句后紧跟时间戳。 - 配置 `dmlog.properties` 文件,指定日志路径(注意 Windows 下路径使用 `\\`)。 - 由于 `Dmlog` 会在后台数据库中创建 `log_commit` 表,因此在运行前需确保该表不存在,或已做好备份。 - 避免在生产环境中使用 `Dmlog`,以免对数据库性能造成影响。 ### 数据库启动失败解决方法 1. **检查数据库实例状态** - 使用达梦数据库管理工具或命令行检查数据库实例是否处于异常状态。 - 如果数据库处于“关闭”或“异常”状态,尝试手动启动数据库。 2. **检查数据库文件完整性** - 确认数据库数据文件、日志文件和控制文件是否完整且未损坏。 - 如果发现文件损坏,可尝试从备份中恢复。 3. **检查端口和网络配置** - 确保数据库监听端口未被占用或防火墙阻止。 - 检查网络配置,确保客户端可以正常连接数据库。 4. **检查权限和用户配置** - 确认数据库启动用户具有足够的权限访问数据库文件和目录。 - 检查 `dm.ini` 文件中的用户权限配置是否正确。 5. **重新启动数据库服务** - 如果数据库因临时性错误导致启动失败,尝试重启数据库服务。 - 在重启前,确保所有数据库连接已断开,并清理相关进程。 ### 示例代码:手动触发检查点 ```sql -- 手动执行 CHECKPOINT() 函数 CHECKPOINT(); ``` ### 示例代码:使用 Dmlog 工具分析 SQL 日志 ```bash # 配置 dmlog.properties 文件 log.path=/path/to/sql/logs # 运行 Dmlog 工具 java -jar Dmlog.jar ```
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值