故障处理

数据库表数据误删,如何恢复

首先确定是什么时候做的操作?数据库是否有备份?有备份的情况下数据可以恢复到任意时间点。如果没有备份一般是无法恢复的

数据库系统必须保证即使发生故障,也可以保障数据的完整性和一致性。支持故障恢复的技术主要是日志,日志以一种安全的方式记录数据库系统变更的历史信息,一旦系统出现故障,数据库系统可以根据日志将系统恢复至故障发生前的某个时刻。数据库系统的日志分为两种类型:

  • REDO 日志,在数据被修改后记录它的新值。
  • UNDO 日志,在数据被修改前记录它的旧值。

另外,当服务器处于归档模式时,如果数据库发生故障,通过备份文件和归档日志可以恢复到指定时间点。具体方法可以参考《DM 备份与还原》手册(手册位于数据库安装路径 /dmdbms/doc/special 文件夹下)。

误删除 undo/redo 日志怎么办

分以下两种情况:

如果有备份文件

如果有备份文件,可以重新初始化一个新的数据库(初始化参数要和原库一样,比如页大小、大小写敏感、字符集等,这些可以在 DM 数据库安装路径,../data/DAMENG 目录下以 dminit+日期时间.log 命名的文件中查询),然后将备份文件和归档日志文件拷贝到新的环境,然后再进行备份 + 归档的还原操作。

如果没有备份文件

如果没有备份,可以通过修改永久魔术值的方式来恢复,但是这种情况下有可能丢失数据。方法如下:

  • 重新初始化一个新的数据库,(初始化参数要和原库一样,比如页大小、大小写敏感、字符集等,这些可以在 DM 数据库安装路径,../data/DAMENG 目录下以 dminit+日期时间.log 命名的文件中查询)。
  • 将步骤 (1) 中重新初始化的数据库中 DAMENG01.log、DAMENG02.log 文件拷贝到当前丢失 REDO 日志的库目录下。
  • 使用 dmmdf 工具获取 SYSTEM.DBF 的 db_magic,并记录下来。
[root@dmyanshi2 bin]# ./dmmdf /data/DAMENG/SYSTEM.DBF 1
1 db_magic=1394176795
2 next_trxid=34742179
Please input which parameter you want to change(1-2), q to quit: q
  • 使用 dmmdf 工具设置 DAMENG01.log 文件的 db_magic,设置为步骤 (3) 中记录的值。
[root@dmyanshi2 bin]# ./dmmdf /data/DAMENG/DAMENG01.log 2
1 sig = DMRLOG
2 ver = 7001
3 chksum = 0
4 dbversion = 0x70008
5 sta = 1
6 n_magic = 7
7 db_magic = 1411700695
8 clsn_fil = 0
9 cur_fil_id = 0
10 next_seq = 0
11 arch_seq = 0
12 len = 67108864
13 free = 4096
14 clsn = 0
15 clsn_off = 4096
16 arch_lsn = 0

You can only reset sta(5) or db_magic (7) or clsn (14).
Please input the num which one you want to change, q to quit: 7
Input the new value: 1394176795
1 sig = DMRLOG
2 ver = 7001
3 chksum = 0
4 dbversion = 0x70008
5 sta = 1
6 n_magic = 7
7 db_magic = 1394176795
8 clsn_fil = 0
9 cur_fil_id = 0
10 next_seq = 0
11 arch_seq = 0
12 len = 67108864
13 free = 4096
14 clsn = 0
15 clsn_off = 4096
16 arch_lsn = 0

Do you want to quit and save the change to file (y/n): y
Save to file success!
  • 重新启动数据库即可。

表空间的数据文件被删除了,想删除表空间,如何解决

数据文件被删除,那这部分的数据是丢失的,数据库无法正常启动。处理方式是将控制文件转成文本文件,在控制文件中把对应表空间信息删除,再把文本文件转成控制文件,删除对应的数据文件,最后启动数据库即可。

具体操作如下:

  • 将控制文件转换成文本文件

切换到数据安装路径如:/opt/dmdbms/bin/bin 执行 ./dmctlcvt help 可以查看到 dmctlcvt 工具的具体情况,如下图所示:

dmctlcvt 帮助信息

将 dm.ctl 文件转换成 dm.txt 文件,如下所示:

./dmctlcvt TYPE=1 SRC=/opt/dmnew/data/DAMENG/dm.ctl DEST=/opt/dmnew/data/DAMENG/dmctl.txt
  • 删除掉 dmctl.txt 中被删除的数据库文件指定的路径。
  • 将 dmctl.txt 生成 .dm.ctl 文件执行以下操作:
./dmctlcvt TYPE=2 SRC=/opt/dmnew/data/DAMENG/dmctl.txt DEST=/opt/dmnew/data/DAMENG/dm.ctl

超出全局 hash join 空间

首先我们讲一个故事:

你是上帝视角【1】,你给了小明 100 个棒槌【2】,这个时候来了 10 个叫做小花的人,小花可以去仓库里拿面粉做包子,但是做一次包子,需要借用小明的棒槌,假如每一个小花借用 10 个棒槌,如果同时来了 11 个小花,前 10 个小花都能借到棒槌,第 11 个小花去找小明借棒槌的时候,小明就告诉她:超出我的棒槌个数了,小花做包子失败。这句话翻译一下就是:数据库服务器报错超出全局 hash join 空间,应用请求在数据库执行失败

但是,每一个小花根据自己的工作量,需要的棒槌个数并不一定必须是 10 个。也就是说,只有来的小花把棒槌都借用完,小明才会报错。但是小明也不是一直会报错,只要有任何一个小花,事情做完了,把借用的棒槌还回来,小明就又可以支撑新的小花。

上面这个故事,对应两个参数,如下图所示:

参数信息

(图片来源:《DM 系统管理员手册》dm.ini 的介绍,手册位于数据库安装路径 /dmdbms/doc 文件夹下。)

  • 小明一共有多少个棒槌,由 HJ_BUF_GLOBAL_SIZE 设置,默认值是 500
  • 一个小花最多可以借多少个棒槌,由 HJ_BUF_SIZE 设置,默认值是 50

还有一个参数控制小明一次给小花多少个棒槌(比如小明要给小花 10 个棒槌,可以是一次给 1 个给 10 次,也可以是一次给 5 个给两次,这两种代价是不一样的)。一次给多少个,取决于以下参数:

参数信息

(图片来源:《DM 系统管理员手册》dm.ini 的介绍,手册位于数据库安装路径 /dmdbms/doc 文件夹下。)

好了,我们回到问题,如果遇到小明报错了怎么办呢?

  • 解决方法一

很多情况下,小花实际上只需要 1 个棒槌、一分钟内就能把事情做完,结果她却用了 10 个棒槌,一天都没有把事情做完,占用的这 10 个棒槌也一直没有还给小明。

换句话说就是要优化语句,消除掉这些不聪明的小花。遇到这个问题的优先核心方法是:找出不聪明的小花,让她变聪明——找到慢语句,进行优化。

  • 解决方法二

扩大小明的棒槌个数,增大 HJ_BUF_GLOBAL_SIZE 数值。

或者是减小单个小花可以借用的棒槌上限,改小 HJ_BUF_SIZ 数值。(有人会问,小花要 10 个棒槌,现在你给她设置成 5 个,她还能干活么?答案是可以,哪怕限制小花最多只能借用 1 个棒槌,她也可以干活,只是工作时间会久一点。同样的,也不是一次性给的越多越好,如果本身只需要 5 个,一次性给了 10 个,也没有意义,工作效率并不会提高。)

如果确认系统中预期的 SQL 均是符合预期的计划,效率均没有问题,确实需要高并发,就必须提高 HJ_BUF_GLOBAL_SIZE/HJ_BUF_SIZ 的比值。同时,又由于前一个参数是静态参数(修改该参数后,需要重启数据库服务后才可以生效),所以应急策略(不能重启数据库的情况下)的处理方式,只有【调小 HJ_BUF_SIZ 数值,这个参数是动态参数,修改后立即生效】。等有机会重启数据库服务时,再在重启数据库服务前,适当调大 HJ_BUF_SIZ 数值,同时也需要保持较高的 HJ_BUF_GLOBAL_SIZE/HJ_BUF_SIZ 的比值。

注意

修改数据库参数的方式: Sp_set_para_value(1,’参数名字’,参数值);--当成 SQL 执行;对于动态参数,直接修改后,立即生效;如果是静态参数,如此修改,会报错:无法修改静态配置参数。 Sp_set_para_value(2,’参数名字’,参数值);--当成 SQL 执行;对于动态参数或者静态参数都可以用,修改后,需要重启数据库服务后才生效。

数据库表被 truncate 后能否找回数据

不能找回,truncate 删除表数据是不可逆的。只能看能否通过备份 + 归档日志的方式,将数据库还原到指定时间点的方式来找回该表的数据。

DM 数据库异常宕机原因排查

当数据库运行过程中发生异常宕机后,需要结合数据库运行日志联合分析原因。如果怀疑是因 SQL 导致的问题,可以通过 DM 提供的 dmrdc 命令行工具抓取到数据库宕机时服务器所有会话线程对应的 SQL 语句,使用格式为:./dmrdc sfile=src_file dfile=dest_file

例如生成 core 文件为 core.19456,则应该执行:./dmrdc sfile=core.19456 dfile=core_19456.txt

待分析完成后,我们可以根据生成的 core_19456.txt,查看到数据库服务器所有会话线程对应的 SQL 语句,其中 SQL 语句前面的中括号数值表示对应线程号,对应堆栈信息中的 LWP 号。我们可以使用 gdb 命令 配合 thread apply all bt 打印出所有线程堆栈,一般导致宕机的 SQL 在【Thread 1】上,我们可以在测试环境中尝试重现宕机现象,如果能够重现则可以将此问题交由达梦技术工程师来处理。

信息

其他类型被强制转成科学计数法的格式

其他类型被强制转成科学计数法的格式 / 比如 100 变成 1E+2% / 10 变成 1。

【解决方法】

可访问达梦云适配中心下载试用,下载最新版数据库,安装的时候选择驱动,将现在的出现问题的驱动换成最新的驱动。

打开管理工具报错:Locking is not possible in the directory

问题截图

【问题解决】

有如下两种解决方法:
方法 1:
可以尝试删除安装目录下的 .fileTableLock 文件 ,再次打开达梦管理工具时会自动生成一个这个 lock 文件。
举例:如下是安装目录,找到 tool 目录下对应的 fileTableLock 文件,删除后再启动管理工具。
目录截图

方法 2:

打开位于../tool 目录下的 manager 配置文件,manager.ini 添加参数 -Dosgi.locking=none,并保存生效。

修改 manager.ini

控制文件 dm.ctl 被误删,启动报错:[code:-803]

【问题详情】

Read ini error,name:CTL_PATH,value:xxxxxx
[invalid ini config value]
nsvr_ini_file_read failed,
[code:-803]

启动数据库报错如下:

报错截图

【解决方法】

1)通过 ctl_bak 找回,用最近的一个 dm_xxx.ctl 改名启动

信息截图

2)详情参考:

控制文件

数据文件 MAIN.dbf 或者自创表空间被误删

【问题详情】

信息截图

信息截图

【解决方法】

详细解答请参考:人为操作故障恢复到指定时间点

数据文件 ROLL.dbf,SYSTEM.DBF 被删后无法启动报错

【问题详情】

信息截图

信息截图

【解决方法】

详细解答请参考:

数据文件恢复到指定时间点

误删除 TEMP.DBF 怎么处理

TEMP.DBF 被删后,重启数据库会自动生成一个新的。

信息截图

undo 日志损坏

【恢复方法】

undo 损坏优先选择“备份 + 归档”恢复,从实例日志获取故障时间;无备份归档的情况下,可以选择跳过 ROLL.DBF 启动数据库临时启动数据库(危险操作,可能破坏事务的原子性)。修改 dm.ini 参数 PSEG_RECV 为 0 。

注意

PSEG_RECV 参数释意: 系统故障重启时,对活动事务和已提交事务的处理方式。 0:跳过回滚活动事务和 PURGE 已经提交事务的步骤。 1:回滚活动事务并 PURGE 已经提交事务; 2:延迟 PURGE 已提交事务,延迟回滚活动事务; 3:回滚活动事务,延迟 PURGE 已提交事务。

redo 日志损坏,报错[-723][-717]

【问题详情】

举例:下面是断电后导致 redo 损坏的一个报错信息;

日志:Read rfil ['/data/dmdbms/data/DAMENG/DAMENG02.log'] from offset[67042304] failed,code [-723]
前台:main rfil [/data/dmdbms/data/DAMENG/DAMENG01.log]'s grp collect 0 invalid recv_pwr record.

【恢复方法】

若备份归档文件都存在:

redo 损坏优先选择“备份 + 归档”恢复,从实例日志获取故障时间;

无备份归档的情况下,可以选择替换 redo 日志临时启动数据库(危险操作,可能会丢失一部分数据),然后将数据迁移出来。

若无法使用备份归档恢复下,替换 redo 启动数据库步骤:

  • 命令模拟 redo 日志损坏
dd if=dminit20210203144245.log of=TEST01.log

信息截图

  • 查看初始化日志,观察初始化参数,重新初始化一个新的实例并前台启动一次
./dminit path=/home/dmdba/data/dmdbms port_num=5237 db_name=TEST
./dmserver /home/dmdba/data/dmdbms/TEST/dm.ini
  • 查看故障库的 db_magic 值和 pemnt_magic 值
./dmmdf type=1 file=/home/dmdba/data/TEST/SYSTEM.DBF

信息截图

备注:db_magic:数据库魔数;pemnt_magic:数据库永久魔数

  • 修改新库的 db_magic 值和 pemnt_magic 值并保存
./dmmdf type=2 file=/home/dmdba/data/dmdbms/TEST/TEST01.log

信息截图

信息截图

  • 将修改后的 redo 挪到故障库下,尝试启动数据库
故障库:mv TEST01.log TEST01.log_old
新库:cp TEST01.log /home/dmdba/data/TEST/

信息截图

  • 此时已经启动起来的数据库仍然存在隐患,应立即完成数据的迁移工作,防止再次发生宕机事故。

迁移方式采用 DTS 或逻辑导出导入。

在新的库上需要和故障库创建相同的用户及密码,并为每个用户指定表空间,分配数据文件。

--在已暂时启动的故障库
--查询用户名,用户默认表空间,表空间所在路径
select username,DEFAULT_TABLESPACE,profile from dba_users;

信息截图

数据库页损坏

  1. 如果数据库仍可以启动

实例正常启停一次,然后执行下列语句:

./dmdbchk  path=/home/dmdba/data/TEST/dm.ini

bin 目录下会生成一个 dbchk_err.txt,可能会记录有一些索引或者表错误,可以重建再做 dmdbchk 。

  1. 如果实例不能启动

关闭 IGNORE_FILE_SYS_CHECK 参数

备注

IGNORE_FILE_SYS_CHECK 参数说明: 默认 0,检查文件系统。1,不检查文件系统。

磁盘问题导致故障

【问题描述】

os_file_flush error!handle:3,code:30,desc:Read-only file system/error 请联系存储厂商进行处理。

磁盘空间不足导致故障:日志报错 out of space

日志报错:

tablespace 7 fail to extend.Please check disk space or extend attribbute of data files.
tablespace 6 fail to extend.Please check disk space or extend attribbute of data files.
ARCH_DEST[/opt/dmdbms/data/DAMENG/arch] will be out of space.

信息截图

【问题解答】:

  1. 通过 df -h 查看当前归档文件所在目录(以/dmarch 为例)的空间使用情况;
  2. 查看定时删除备份有没有执行?--如果没删,可以删除。
  3. 查看 dmarch.ini 配置文件中的 ARCH_SPACE_LIMIT 参数设置,确认归档日志使用空间的大小限制是否超过/dmarch 的大小。此时分为两种情况:
    情况一:ARCH_SPACE_LIMIT 设置的值大于/dmarch 的最大值;
    此时考虑三种方法:
    (1)进入/dmarch,备份归档日志到其他空闲磁盘,然后删除比较旧的归档日志使/dmarch 的可使用空间大于 10% 左右(谨慎操作)。
    (2)备份 dmarch.ini,同时修改 ARCH_SPACE_LIMIT 的值到/dmarch 总大小的 90% 左右,使归档日志可以正常写入而不至于写满。
    (3)对/dmarch 的空间进行扩容。

情况二:ARCH_SPACE_LIMIT 设置的值小于/dmarch 的最大值。
此时考虑是否其他应用占用了归档空间。进入/dmarch 确认是哪些非归档日志文件占用空间,确认占用的应用,挪走其他非归档日志文件,释放空间,同时修改其他应用对此空间的使用。

注意

(1)导致归档日志空间被写满的原因有比较多种,当归档日志空间被非当前数据库实例使用,而导致数据库归档日志被写满无法启动,此种情况需要判断是什么应用占用了这个空间,然后确认是否可以直接删除或者将其备份到其他地方后删除。做完此步骤后,还需将数据库的归档日志空间独立出来,以免后续再次出现类似情况。 (2)ARCH_SPACE_LIMIT 设置大于归档日志空间所在磁盘的最大容量。此种情况下,建议备份历史的归档日志后,删除部分归档日志,腾出空间,同时将 ARCH_SPACE_LIMIT 的值调整到归档日志空间磁盘大小的 90% 左右,或者在对归档日志使用的目录进行扩容后,再进行重启数据库。

使用 Manager 管理工具的时候,出现卡顿的情况

应用出现卡顿一般是由于阻塞造成。但是 Manager 管理工具如果产生阻塞的事务,一般只是报错锁超时,或者当前窗口执行的语句一直在执行状态。

Manager 管理工具出现卡顿的情况,常见于两种场景:

  1. 打开管理工具的机器的内存或 CPU 资源不足;
  2. 旧版本客户端在执行耗时很长的 SQL 或执行耗时很长的操作时,可能会存在卡顿的情况。

数据库卸载后,只剩数据 data 文件夹里面文件,如何修复

重新安装数据库,安装时不用重新初始化库,将 data 目录全部拷贝到新安装的数据库安装目录下,只需要通过工具重新注册数据库服务,然后正常启动数据库即可。

运行 dbms_repository_snapshot.create_snapshot() 生产快照的时候会卡住

快照的表空间默认只有 10 GB。

使用命令:CALL SP_INIT_AWR_SYS(0);  可以清理一下 AWR 环境,扩大 AWR 报告的表空间数据文件上限或者加一个数据文件,如下命令操作:

alter tablespace "SYSAUX" datafile 'SYSAWR.DBF' autoextend on maxsize 102400;
alter tablespace "SYSAUX" add datafile 'SYSAWR_APPEND.DBF' size 128 autoextend on;

在更新 /updte 数据的时候突然卡住,没有任何报错

可能原因:update/ 更新同一行语句需要提交之后才能修改,默认行锁。

  1. 提交或回滚产生阻塞的事务

只需要在发生阻塞的会话下提交或回滚事务,锁自然会被释放,阻塞解决。

  1. 关闭产生阻塞的会话

我们也可以使用系统过程 SP_CLOSE_SESSION(SESS_ID) 来关闭对应的会话。

disql 执行语句后无法退出,Ctrl+C 也没用

exit 退出,或者 kill 掉 disql 进程。

V$SESSIONS 视图中获取的 LAST_SEND_TIME 和 LAST_RECV_TIME 不准确

【问题描述】

尝试通过 V$SESSIONS 中的 LAST_RECV_TIME 和当前系统时间来计算当前活动会话的执行时间,发现连接的 LAST_SEND_TIME 和 LAST_RECV_TIME 返回值不正确,均为 1970-01-01 08:00:00.000000

LAST_RECV_TIME 值不对

【解决方法】

  • 查看 ENABLE_MONITOR 参数的配置值
SELECT PARA_NAME,PARA_VALUE FROM V$DM_INI WHERE PARA_NAME='ENABLE_MONITOR';

ENABLE_MONITOR 值查询

  • 使用管理员用户连接数据库,动态修改 ENABLE_MONITOR 参数值,开启系统监控功能;
SP_SET_PARA_VALUE(1,'ENABLE_MONITOR',1);

ENABLE_MONITOR 值设置

  • 新建数据库连接,查看新建会话的 LAST_SEND_TIME 和 LAST_RECV_TIME
SELECT CREATE_TIME,LAST_SEND_TIME,LAST_RECV_TIME FROM V$SESSIONS;

LAST_RECV_TIME 值不对

环境变量或者 dm_svc.conf 配置不合理导致 disql 登录不正常

【问题描述】

  • 现象 1:disql sysdba/SYSDBA@192.168.xx.xx:5236 登录本地服务器,未提示已登录,执行 SQL 报 “未连接”,需要 login,相同命令登录远程服务器正常,远程客户端登录本服务器也正常,切换到 dm 的 bin 目录下执行 ./disql sysdba/SYSDBA@192.168.xx.xx:5236 任何服务器均可登录成功。

【解决方法】

  • 说明客户端和服务端均可以正常使用,区别就是使用了环境变量的方式登录本地异常;检查环境变量,对比其他节点,改成一样,问题解决了。
  • 总结:环境变量在初始安装后,额外添加或者修改的项目,确保知悉其影响,不合适的配置可能会导致 disql 登录异常

【问题描述】

  • 现象 2:运行./disql 登录任意 ip:port 或者是服务名,均持续卡住无返回,其他节点上客户端均正常

【解决方法】

  • 检查 dm_svc.conf 文件,配置如下:
TIME_ZONE=(480)
LANGUAGE=(cn)
LOGIN_MODE=(2)    # 只连主机
LOGIN_STATUS=(4)  # 只连OPEN状态
SWITCH_TIMES=(1000)             #无法建立符合要求的连接时,循环遍历服务名列表的次数
SWITCH_INTERVAL=(1000)  #无法建立符合要求的连接时,两次遍历间的时间间隔
#DO_SWITCH=(1)
DB_ALIVE_CHECK_FREQ=(10000)
DB_ALIVE_CHECK_TIMEOUT=(10000)
SOCKET_TIMEOUT=(20000)

DWHW=(192.168.104.31:45236,192.168.104.32:45236)

将其中非默认的全局参数全部还原(删除)后,恢复正常。

总结:该文件中 SWITCH_TIMES 和 SWITCH_INTERVAL、LOGIN_MODE 建议保持默认,不要随意调整,以上值不合理,会导致连接迟迟无法成功建立。另外,上面是全局配置,不建议在这里修改参数,建议在下面新建需要的别名的专用参数。

管理工具 “编辑数据” 报错 “结果集不可更新”

【问题描述】
使用管理工具“编辑数据”功能按钮,提示:”结果集不可更新,请确认查询列是否出自同一张表,并且包含值唯一的列“。如图:

结果集不可更新

【解决方法】

主要有三种处理方法:

第一种:添加主键约束

alter table "SYSDBA"."TABLE1" add constraint PK_C1 primary key("C1");

第二种:添加唯一约束

alter table "SYSDBA"."TABLE1" add constraint "CONS_UNQ_C2" unique("C2");

第三种:创建唯一索引

create unique index "IDX_UNQ_C1" on "SYSDBA"."TABLE1"("C1");

kettel 抽取 number 整数类型变为小数、插入 number 类型小数保留精度不对

如果连接类型使用【generic database】,获取整数类型的方法为 getDouble,导致结果变为小数。

例如:数据库中数据为 1922,但通过 kettel 的抽取结果为 1922.0

该问题是由于 kettel 的通用数据源中获取数据的方法存在问题,可通过使用 Oracle 的连接来绕过,连接类型选择 Oracle,jdbc 的 url 以及驱动类均配置为 Oracle。将 dm8-oracle-jdbc16-wrapper.jar 与 DmJdbcDriver.jar 一起放入 lib 目录。

数据库服务器通过管理工具连接本地数据库时,报错-703 服务器模式不匹配

【问题描述】

连接数据库时报错,提示服务器模式不匹配。如下图所示:

结果集不可更新

【解决方法】

检查客户端的 dm_svc.conf 是否配置全局参数 LOGIN_MODE=(1)。
当 LOGIN_MODE 配置成 1 时,连接单机库无法登陆,会抛出“服务器模式不匹配”的报错,去掉此参数即可;通常 LOGIN_MODE=1 为主备集群配置,但需配置集群连接时,将此参数配置成局部参数即可,示例如下:将 LOGIN_MODE=(1)移到[DM_DW]下面

TIME_ZONE=(480)
LANGUAGE=(cn)
DM_DW=(192.168.10.11:5236,192.168.10.12:5236)
[DM_DW]
LOGIN_MODE=(1)

拓展:LOGIN_MODE 参数描述:指定优先登录的服务器模式。0:优先连接 Primary 模式的库,Normal 模式次之,最后选择 Stantby 模式;1:只连接主库;2:只连接备库;3:优先连接 Standby 模式的库,Primary 模式次之,最后选择 Normal 模式;4:优先连接 Normal 模式的库,Primary 模式次之,最后选择 Standby 模式。

达梦 manager 客户端登录提示网络通信异常

  • 检查网络;
  • 检查数据库服务是否启动;
  • 检查防火墙是否开启;
  • 检查网络是否有对端口做限制;

sqlserver 创建 dblink 失败

【问题说明】
windows 环境下,sqlserver 创建链接服务(dblink)连接 DM(安装在 windows 上),ODBC 测试连接成功,信息填写正确,但 sqlserver 创建链接服务时,报未发现数据源名称且未找到数据库驱动。

【解决方法】
由于 windows 文件权限问题导致,未使用 administrator 或对应用户安装时,需要在 DM 安装目录 bin 下手动加入 USERS 用户组。
具体操作为:右键 DM 的 bin 目录,属性-安全中,用户及用户组下点编辑-添加,输入 USERS 添加。之后可以正常创建 sqlserver 至 DM dblink。

启动数据库后应用一连接就 core 掉

【问题分析】

需要根据 core 文件具体分析:

  • 数据库中某张表损坏:可使用 dmdbchk 的方式检查数据文件是否损坏,若表有问题可采用先将有问题的表备份,之后删除重建的方法解决。
    正常关闭 /home/test/dmdbms 目录下的数据库后,用以下语句检查数据文件:
./dmdbchk PATH=/home/test/dmdbms/dm.ini
  • 索引损坏:可以采用直接重建索引的方法解决。

使用 disql 工具操作数据库时提示:连接丢失

【问题解决】

这种情况很可能是数据库突然挂死,查看数据库服务进程是否还在:

ps -ef |grep dms

然后去安装目录下的../log 文件夹下查数据库实例日志,根据日志信息具体分析。

启动数据库报错:System information is invalid,please check ../DAMENG/SYSTEM.DBF or its mirror file

【问题描述】

启动数据库失败,具体报错信息如下:

报错信息

【问题解决】

这是 SYSTEM.DBF 文件损坏了,可通过备份来修复数据库,基于备份进行库级还原和归档恢复到最新状态。
具体方法可以参考《DM 备份与还原》手册(手册位于数据库安装路径 /dmdbms/doc 文件夹下)。

vpn 环境下管理工具连接数据库报错:网络通信异常

【问题描述】

telnet 端口正常,数据库服务已启动,利用 VPN,管理工具连接报错:网络通信异常。

【问题解决】

由于使用 vpn 连接,因此在 manager.ini 追加参数,修改为只支持 IPV4。

-Djava.net.preferIPv4Stack=true

数据库报错 IO timeout overtime 3 of IO_TIMEOUT

【问题描述】

数据库日志记录: check page IO timeout overtime 3 times of IO_TIMEOUT,please check disk.
如下图所示:

日志记录

【问题解决】

出现该报错的原因是磁盘故障导致写 redo 一直写不进去,等待了 IO_TIMEOUT*3 次以后还是失败,直接 halt。
可通过调整 dm.ini 中 IO_TIMEOUT 参数值,将其放大(IO_TIMEOUT 参数为动态参数),并检查磁盘的故障问题。

DM6 数据库出现宕机现象

【问题描述】

DM6 版本数据库服务启动后,运行一段时间后数据库 core 了,且数据库宕机时数据库日志中断。

【问题解决】

通过以下步骤进行排查:
1.进入数据库主目录,输入以下命令查看数据库堆栈信息;
gdb dmserver core.**** 依次输入以下命令:
bt
f 0
p *ctl
堆栈内容显示:Cannot access memory at address 0x0 就可以确定为缓冲区不够了,导致的数据库宕机。
2.查看当前执行的 SQL 语句;
依次输入 bt
f 6
p stmt->sess->sqls
3.确定为执行某 SQL 时缓冲区内存不足,造成数据库宕机故障。
4.根据服务器可分配的内存来合理调整配置文件(dm.ini)中 buffer 和 max_buffer 的值,dm6 数据库 buffer 的计算公式为:
占用的内存(单位 G)=(buffer * pagesize)/1024/1024。Buffer 的推荐值,系统缓冲区大小为可用物理内存的 60%~80%,有效值范围(100-16777216)。

达梦 DSC 集群,其中一个节点宕机,另一节点正常提供服务

【问题解决】

出现该问题是由于宕机节点使用的操作系统信号量被清除,导致该节点进程异常中止,重新启动数据库可正常运行,但后期仍会不定时出现宕机现象。
解决方案为修改 /etc/systemd/logind.conf 配置文件中的 RemoveIPC 参数,将 # 注释去掉,并修改 yes 为 no。

linux 下数据库运行过程中误删除某个表空间数据文件,如何快速进行恢复

【问题解决】

数据库运行中误删除了某个表空间数据 dbf 文件,不用停止或重启数据库,尽快进行以下操作:

  1. SYSDBA 登录数据库调用存储过程 SP_TABLESPACE_PREPARE_RECOVER(tablespace_name)尝试进行表空间恢复;
  2. 查找文件副本,首先找到数据库 dmserver 服务 pid(命令:ps - ef|grep pid),操作系统执行 ls /proc/pid/fd -l 找到带有 deleted 字样的 dbf 文件;
  3. 将文件 cp 到原数据文件存放位置,给用户权限;
  4. SYSDBA 登录数据库调用系统过程 SP_TABLESPACE_RECOVER(ts_name)完成文件修复。

数据库服务无法启动,执行服务启动命令后提示:os_file_flush error desc:Read-only file system

【问题分析】

报错截图如下:

报错截图

此问题多出现在具备磁盘阵列的数据库环境上,数据文件存储在磁盘整上,当阵列链路出现过中断或者阵列掉电重启的情况下会造成文件系统只读。数据库服务启动后在进行数据文件变更操作出现此问题。可以尝试重新挂载文件系统,然后重启数据库服务。

数据库服务突然中断

【问题分析】

可检查 bin 下没有 core 文件产生,分析 core 文件,或检查数据库运行日志没有告警或报错信息。

例如:当数据库服务突然中断,检查查看操作系统日志/var/log/messages.debug 会发现明显的报错,Out of Memory: Kill process 类似的错误信息。如下图所示:

日志报错截图

此时表示数据库因内存不足而出现服务中断。应查看内存使用情况 free -g ,适当调整数据库 buffer、memory_target、recycle 等参数。

服务无法启动,前台启动报错:非法指令(核心已转储)

【问题描述】

服务无法启动,前台启动报错为:非法指令(核心已转储)

前台报错截图

服务日志中出现 FATAL 致命错误:Redo log try flush over space;code -5,dm_sys_halt now!

日志报错截图

【问题解决】

日志报错的含义为“日志环被冲破”。随着业务规模和数据量的增长,事务中所包含的 DML 操作引起的变化量会持续增长,若某一时间点,进行一个或多个长事务,事务中包含有大量的 DML 或 DDL 操作,就会引发 redo 日志容量不足的问题,即冲破日志环。
解决方案:
1、完整备份备份故障时刻实例数据;
2、尝试调大 RLOG_RESERVE_SIZE 参数, 或者增加在线日志大小和个数;
2、如果数据库已无法启动报错,源实例中修改 dm.ini 中参数 RLOG_CHECK_SPACE=0(日志刷盘时,不检查日志空间是否溢出)后启动服务即可。启动后第一时间备份数据,迁移至新的环境。

启动 dmwatcher 报错:fail to read ini file

【问题描述】

[dmdba@localhost bin]$ ./dmwatcher /soft/dsc/config/dsc0_config/dmwatcher.ini
DMWATCHER[4.0] V8
Invalid [arch_name] or the file contains unrecognized characters!
Read ini file(/soft/dsc/config/dsc0_config/dmarch.ini) error in line 1, code(-104)
Read dm.ini(/soft/dsc/config/dsc0_config/dm.ini) failed, code = -104!
fail to read ini file

【问题解决】

从报错信息来看,需核实对应的配置文件。除了核实该文件是否存在、文件权限是否正确之外,还需要核实配置文件中是否存在全角的空格。
若配置文件内容及权限没有问题,则需注意文件中全角和半角符合的问题,建议将配置文件是复制到 notepad 中去看,一定要设置“显示空格和制表符”的选项,便于排查。

全角半角对比

设置“显示空格与制表符”:

设置 notepad

注意

配置文件尽量不要使用从 windows 上拷贝复制文件,同时检查空格和换行符。

数据库版本升级后,DmAPService 服务启动失败报错

【问题描述】

数据库版本升级后,DmAPService 服务启动失败,报错信息如下:

---脚本服务启动报错
[root@MI8SE-liuzhenbindeMI bin]# ./DmAPService start
Starting DmAPService: touch: cannot touch '_REPLACE_SELF_DM_HOME/log/dmsvc_sh.log': No such file or directory
chown: cannot access '_REPLACE_SELF_DM_HOME/log/dmsvc_sh.log': No such file or directory
./DmAPService: line 412: _REPLACE_SELF_DM_HOME/log/dmsvc_sh.log: No such file or directory
su: user  does not exist
                                                          [ FAILED ]
cat: _REPLACE_SELF_DM_HOME/log/DmAPService.log: No such file or directory

---系统服务启动报错
[root@MI8SE-liuzhenbindeMI bin]# systemctl start  DmAPService
Job for DmAPService.service failed because the control process exited with error code.
See "systemctl status DmAPService.service" and "journalctl -xe" for details.
[root@MI8SE-liuzhenbindeMI bin]# systemctl status DmAPService.service
● DmAPService.service - DM Assistant Plug-In Service(DmAPService).
  Loaded: loaded (/usr/lib/systemd/system/DmAPService.service; enabled; vendor preset: disabled)
  Active: failed (Result: exit-code) since Sat 2022-01-22 11:04:56 PST; 7s ago
 Process: 17659 ExecStart=/soft/dmdbms/bin/DmAPService start (code=exited, status=1/FAILURE)
Main PID: 6129 (code=dumped, signal=SEGV)

Jan 22 11:04:56 MI8SE-liuzhenbindeMI systemd[1]: Starting DM Assistant Plug-In Service(DmAPService)....
Jan 22 11:04:56 MI8SE-liuzhenbindeMI DmAPService[17659]: mkdir: cannot create directory ‘_REPLACE_SELF_DM_HOME’: Permission denied
Jan 22 11:04:56 MI8SE-liuzhenbindeMI DmAPService[17659]: chown: cannot access '_REPLACE_SELF_DM_HOME/log': No such file or directory
Jan 22 11:04:56 MI8SE-liuzhenbindeMI DmAPService[17659]: mkdir: cannot create directory ‘_REPLACE_SELF_DM_HOME’: Permission denied
Jan 22 11:04:56 MI8SE-liuzhenbindeMI DmAPService[17659]: chown: cannot access '_REPLACE_SELF_DM_HOME/bin/pids': No such file or directory

【问题解决】

该报错是由于升级数据库版本直接替换 bin 目录,导致 DmAPService 脚本中 DM_HOME 环境变量信息变化。
解决方案:手动修改 DmAPService 脚本中 DM_HOME 环境变量,默认为“_REPLACE_SELF_DM_HOME”,修改为数据库实际安装路径,如"/opt/dmdbms"。

isql 或管理工具登录 DM6 数据库失败

【问题解决】

可按照如下顺序进行排查:
1、检查数据库服务是否正常,是否有内存转储文件产生。
2、检查数据库进程 cpu 是否陷入循环。
3、检查是否有 io 等待。
4、检查内存使用是否正常。
5、检查数据库运行日志是否正常,检查点是否已固定频率刷新。
6、检查追踪日志内容正常刷新。
7、检查链接数是否充足:使用 netstat -ap|grep xxx|wc -l 检查,对比 ini 中最大连接数设置。若确认问题为连接数不足,则根据 netstat 命令结果,找到对应应用程序,沟通后由对应厂家停止应用进程,重新登录数据库即可。

dm6 管理工具返回结果集太大,中断加载,显示不全

【问题分析】

原因:dm6 客户端 JVM 堆内存的分配不够。
-Xms 为最小分配的堆内存,默认为物理内存的 1/64;
-Xmx 为最大分配的堆内存,manager.sh 中默认配置为 512m;

解决方法:适当调大-Xmx。在 manager.sh 中修改 Xmx512m 到 Xmx1024m 或者更大,视情况定。

数据库 roll.dbf 损坏需要替换

【问题解决】

当数据库出现以上问题时,可通过以下步骤进行解决:

1、修改数据库 dm.ini 参数 PSEG_RECV=0 后重启数据库。其中修改参数 PSEG_RECV=0 后,可跳过回滚启动数据库;
2、正常停止数据库,将 roll.dbf 文件 mv 至其他目录;
3、按照该库参数初始化一个新数据库,并进行正常启停操作;
4、将新数据库生成的 roll.dbf 拷贝至原数据库的原 roll.dbf 路径;
5、修改原数据库 dm.ini 参数 PSEG_RECV=1 后启动数据库。

perf top 异常热点 lock_release_check_savepoints

【问题分析】

如下图所示:

报错截图

触发这个热点的条件通常是因为一个事务上的 savepoint 太多了,触发场景比较简单,例如使用全表扫描,获取大量数据,但是事务一直不提交,并且不获取全部数据,这样每次前 100 行就会加一个 savepoint,这样会导致事务的 savepoint 残留。
savepoint 的产生机制:对于每一个 SQL 命令,可以参考 java 的 try catch 机制。
1、首先我们创建一个 savepoint p1;
2、然后 try {
lock dict objects;
SQL statment;
}
3、当出现异常时 catch {
rollback to savepoint p1;
remove savepoint p1;
send message;
}

当我们的热点函数中出现 savepoint 时,可以通过视图来查询:

Select  a.trx_id,a.sess_id,datediff(ss,a.last_recv_time,sysdate)ss,sf_get_session_sql(a.sess_id),b.savepoint_cnt,b.ins_cnt,b.del_cnt,b.upd_cnt,b.upd_ins_cnt
from v$sessions a,v$trx b
where a.trx_id = b.id

找到对应的事务后再针对性的进行分析处理。

DMMPP 主备集群登录后查询表报错:MPP 站点信息不匹配

【问题解决】

问题原因:该表的表结构在每个节点上不一致,有些节点有这张表,有些节点没有这张表。可通过以下步骤解决:
1.用 MPP 局部登录,登录每一个节点看是否有这个表;
2.备份该表的数据;
3.在有这个表的节点 MPP 局部登录后执行:SP_SET_SESSION_LOCAL_TYPE (1);,并删除该表 drop table tab_name;
4.再全局登录 DMMPP 重新创建该表,最后将数据导入。

使用低版本的 bin 目录启动集群失败

【问题描述】:

某环境 DM8 数据库中,前期使用替换 bin 目录的方式升级主备集群环境(从 8.1.2.84 升级到 8.1.2.94),运行一段时间后,想测试能否使用低版本的 bin 目录来启动主备集群。具体测试步骤如下:

  • 将测试环境中的 bin 目录替换为低版本的 bin。

    [dmdba@dmdb01 dmdbms]$ mv bin bin_new94
    [dmdba@dmdb01 dmdbms]$ mv bin_bak0531/ bin
    [dmdba@dmdb03 dmdbms]$ mv bin bin_new94
    [dmdba@dmdb03 dmdbms]$ mv bin_bak0531/ bin
    
  • 启动主备集群。

image.png

image.png

然而,使用低版本的 bin 目录启动主备集群后,使用非确认监视器发现:集群状态异常,主库自动关闭,备库也处于 mount 状态。

报错信息如下:

(1)监视器信息。

image.png

(2)检查 dm_DW1_01_202206.log 日志:发现是:Server DM8_DCT_VERSION mismatch, version of data is 41, server version is 38. 版本错误导致的。

image.png

(3)检查 dm_dmwatcher_DW1_01_202206.log 日志发现主备节点状态异常。

image.png

【问题解决】:

  1. 使用 dmctlcvt 工具分析 DM8_DCT_VERSION 版本。

    [dmdba@dmdb01 bin]$ ./dmctlcvt TYPE=1 SRC=/dm8/dmdbms/data/DAMENG/dm.ctl DEST=/dm8/dmdbms/data/DAMENG/dm.txt
    DMCTLCVT V8
    convert ctl to txt success!
    
  2. 执行 more dm.txt 发现 DM8_DCT_VERSION=41,如下图

image.png

  1. 修改 DM8_DCT_VERSION 从 41 改成 38。

image.png

  1. 重新生成 ctl 控制文件。

    [dmdba@dmdb01 bin]$ ./dmctlcvt TYPE=2 SRC=/dm8/dmdbms/data/DAMENG/dm.txt DEST=/dm8/dmdbms/data/DAMENG/dm.ctl
    DMCTLCVT V8
    convert txt to ctl success!
    
  2. 重新启动主备集群,检查集群运行状态正常。

  • 使用非确认监视器检查。

image.png

  • 使用 disql 检查集群状态和数据库版本。

image.png

Windows 平台 Manager 调试带绑定变量参数语句时,SRVLOG 中始终缺少[SEL]标签执行信息

【问题描述】:

通过 Windows 平台 Manager 调试带绑定变量的 SQL 时,后台 SVRLOG 中始终缺少[SEL]标签的执行步骤,导致该条目中相应 EXEC TIME 一并丢失,但前台正确返回结果集,SRVLOG 如下图所示:

image.png

【问题分析】:

  • 通过 disql 执行相同命令后台捕获正常。

image.png

  • 通过 Linux 端 Manager 执行相同命令后台捕获正常。

image.png

考虑为 Windowds 平台 java 自身高速缓存导致其在没有发生变化的情况下跳过了执行步骤。

【问题解决】:

  1. 关闭客户端,并删除 workspace 下 manager 中生成的.metadata 目录。

image.png

  1. 找到 Windows 平台对应客户端路径下的 jre 控制面板工具。

image.png

  1. 依次执行临时 Internet 文件设置中的删除文件,并取消 “将临时文件保存在我的计算机上”选项后确定。

image.png

  1. 重新启动 Manager 执行测试,此时后台 SVRLOG 可以正确捕获完整流程。

image.png

image.png

DM6 数据库分离后的数据库附加时提示“数据库未正常分离”

【问题解决】:

此问题主要是由于 linux 下数据文件与数据库安装所使用的用户和组不一致导致。如果不一致,在附加时会出现报错:数据库未正确分离。将所要附加的数据库数据文件权限修改正确后,即可正常进行附加。

微信扫码
分享文档
扫一扫
联系客服