# 初始化脚本执行问题

# 1、DM数据库，初始化后，登录portal，左侧菜单栏全部是乱码

# 问题现象

使用达梦数据库最新版本完成数据库初始化后，以systemadmin用户登录ipaas的portal系统，发现左侧菜单显示为乱码，影响系统正常使用。

# 问题分析

编码格式不匹配：初始化脚本采用UTF-8编码格式，但DM数据库管理工具对SQL文件的编码格式要求存在差异，部分工具默认使用GBK编码读取脚本。
执行环境差异：在数据库初始化过程中，执行UTF-8编码的SQL脚本时，管理工具可能按GBK编码解析，导致中文字符被错误解析和存储。
数据存储源头问题：由于脚本执行时的编码解析错误，导致写入数据库表中的中文菜单数据本身就是乱码，进而影响前端显示。

# 解决方案：调整管理工具编码设置

DISQL工具设置

DISQL是达梦数据库的命令行交互工具，通过设置客户端编码可以确保与数据库字符集匹配。
临时设置（当前会话有效）

-- 登录DISQL后执行
./disql SYSDBA/SYSDBA@localhost:5236

-- 设置为UTF-8编码
SET CHAR_CODE UTF8;

-- 或设置为GBK编码  
SET CHAR_CODE GBK;

-- 查看当前编码设置
SHOW PARAMETER CHAR_CODE;

-- 执行查询验证编码
SELECT * FROM V$CHARSETS;

# 编辑DISQL配置文件
vi $DM_HOME/bin/disql.ini

永久设置（修改配置文件）

# 添加或修改以下配置
[default]
CHAR_CODE=UTF8  # 默认使用UTF-8编码

# 或
CHAR_CODE=GBK   # 默认使用GBK编码

命令行直接指定编码

# 启动时指定编码
./disql SYSDBA/SYSDBA@localhost:5236 CHAR_CODE=UTF8

修改完成后重新执行初始化脚本。

# 总结

# 问题根源定位

初始化脚本编码（UTF-8）与DM管理工具默认解析编码（GBK）不匹配
导致中文字符在入库时被错误解析，形成乱码
最佳实践建议：

# 初始化前检查清单：

确认业务系统支持的字符集
检查SQL脚本文件的实际编码格式
了解DM管理工具的默认编码设置

# 2、安装初始化新环境之后，登录Portal报错：“默认安全策略不存在”

# 问题现象

在iPaaS910版本的Portal系统部署过程中，访问登录页面时，系统报错，提示“默认安全策略不存在”。此错误导致Portal服务无法正常启动或用户无法进行登录操作。

# 问题分析

# 根本原因

该问题的根本原因在于数据库初始化流程未能完整执行。

正常初始化逻辑：在iPaaS910系统数据库首次启动时，业务表 afc_safety_site（安全策略表）的数据会从一个模版表 afc_safety_site_temp 中自动初始化并填充。
实际发生情况：在客户环境中，系统启动时，从 afc_safety_site_temp 到 afc_safety_site 的数据初始化过程失败了。导致 afc_safety_site 表中没有必需的基础数据，因此系统在启动或登录验证时，因找不到默认的安全策略记录而抛出错误。

# 初始化成功标志

通过查看系统启动日志，可以判断初始化流程是否执行成功：

初始化开始：日志中会打印 Begin System Init 的INFO级别日志。
初始化成功结束：日志中会打印 End System Init 的INFO级别日志。

如果日志中仅看到 Begin System Init 而未出现 End System Init，或者在这两条日志之间出现异常堆栈，则说明初始化过程被中断或失败。

# 解决方案

# 数据库权限检查步骤

在实施修复前，建议先检查数据库账号权限，确认是否为根本原因：

确认数据库账号：查看应用配置，确认当前应用使用的是哪个数据库账号连接数据库。
登录数据库：使用DBA权限的账号登录数据库客户端。

执行权限检查SQL：

-- 替换 'your_app_user' 为实际的数据库账号名
-- 查询用户对模版表的查询权限
SELECT grantee, table_schema, table_name, privilege_type 
FROM information_schema.role_table_grants 
WHERE grantee = 'your_app_user' 
  AND table_name = 'afc_safety_site_temp';

-- 查询用户对目标表的增删改查权限
SELECT grantee, table_schema, table_name, privilege_type 
FROM information_schema.role_table_grants 
WHERE grantee = 'your_app_user' 
  AND table_name = 'afc_safety_site';

# 权限判定：

应至少确保用户对 afc_safety_site_temp 有 SELECT 权限;
应确保用户对 afc_safety_site 有 INSERT、UPDATE、DELETE、SELECT 等完整操作权限（或至少拥有 INSERT 和 SELECT 权限用于初始化）;
如果查询结果为空或缺少必要权限，则可确认是权限问题导致初始化失败。

# 确认修改权限后重新启动，确认有End System Init出现，则初始化正常成功，登录没问题。

# 3、数据库初始化报错“无效的表或视图名[XXL_JOB_LOGGLUE]

# 问题现象

在部署某系统（版本910）并连接达梦数据库最新版本进行初始化时，执行初始化脚本过程中报错，错误信息提示：“无效的表或视图名[XXL_JOB_LOGGLUE]”，具体错误码为 -2,106。

# 原因分析

直接原因：初始化脚本在尝试访问或操作名为 XXL_JOB_LOGGLUE 的表或视图时，数据库返回了“对象不存在”的错误。
根本原因：用于执行初始化脚本的数据库账号权限不足。账号缺少 CREATE INDEX（创建索引）的权限。当脚本执行为相关表建立索引时，因权限被拒，导致该条DDL语句执行失败。由于脚本可能在一个事务中或存在依赖关系，这个失败进而引发了后续对该表（XXL_JOB_LOGGLUE）操作时，数据库认为该表不存在或无效的连带错误。

# 解决方案

检查并授予账号必要权限：

权限检查方法：

方法一：查询系统视图：使用待检查的账号登录数据库，执行以下SQL语句查询该账号拥有的系统权限：

-- 查询当前用户被授予的系统权限
   SELECT * FROM USER_SYS_PRIVS;
-- 或者查询包含CREATE INDEX权限的记录
  SELECT PRIVILEGE FROM USER_SYS_PRIVS WHERE PRIVILEGE = 'CREATE INDEX';

方法二：使用达梦管理工具：通过达梦管理工具DM Manager连接到数据库，在左侧对象导航中找到该用户，右键查看“属性”或“权限”选项，在系统权限列表中查看是否包含“CREATE INDEX”权限项。

方法三：角色权限检查：有时权限是通过角色授予的，可以检查用户被授予的角色以及这些角色包含的权限：

 -- 查询用户拥有的角色
 SELECT * FROM USER_ROLE_PRIVS;
 
 -- 查询角色拥有的权限（需要具有相应视图的访问权限）
 -- SELECT * FROM ROLE_SYS_PRIVS WHERE ROLE = '角色名';

权限授予方法：
如果检查发现缺少 CREATE INDEX权限，使用具有足够权限的账户（如SYSDBA）登录数据库，执行以下SQL语句为执行初始化脚本的账号（例如 USER_NAME）授予创建索引的权限：
```
GRANT CREATE INDEX TO USER_NAME;
```
如果需要授予更多常用DDL权限，可以一次性授予RESOURCE角色（通常包含CREATE TABLE、CREATE INDEX、CREATE VIEW等权限）：
```
GRANT RESOURCE TO USER_NAME;
```

重新执行初始化：

确保权限授予成功后，使用配置好的账号，通过官方工具或可靠的命令行方式（如 disql）重新执行完整的数据库初始化脚本。

# 总结

本次初始化报错“无效的表或视图名”并非表结构定义本身的问题，而是由数据库工具兼容性以及账号缺乏 CREATE INDEX 权限共同导致。权限不足使得索引创建语句失败，打乱了初始化流程，最终表现为后续对象无法找到的错误。此案例提示在达梦数据库的部署实践中，需要关注官方工具的选用以及账号权限的完整授予。在初始化脚本执行前，建议通过查询系统视图 USER_SYS_PRIVS 或使用达梦管理工具提前检查账号是否具备必要的DDL权限（如CREATE INDEX、CREATE TABLE等），避免因权限缺失导致部署失败。