kingbase教程FG133-金仓数据库常见问题与解答
本文档汇总了金仓数据库的常见问题与解答，涵盖安装配置、日常维护、备份恢复、性能优化、安全管理等方面的常见问题。风哥教程参考金仓官方文档常见问题解答、系统管理员手册等内容，适合DBA人员和数据库管理人员在日常工作中参考。
Part01-基础概念与理论知识
1.1 常见问题概述
金仓数据库在使用过程中可能会遇到各种问题，这些问题主要集中在安装配置、日常维护、备份恢复、性能优化、安全管理等方面。了解这些常见问题的原因和解决方案，可以帮助DBA人员更快地解决问题，减少系统 downtime。
常见问题的特点：
问题分类：
1. 安装配置类问题
– 安装失败
– 配置错误
– 启动失败
– 连接问题
2. 日常维护类问题
– 空间不足
– 索引问题
– 统计信息问题
– 日志管理问题
3. 备份恢复类问题
– 备份失败
– 恢复失败
– 备份策略问题
– 灾备问题
4. 性能优化类问题
– 慢查询
– 连接数过高
– I/O性能差
– 内存不足
5. 安全管理类问题
– 权限问题
– 访问控制问题
– 审计问题
– 数据安全问题
6. 高可用类问题
– 复制问题
– 故障切换问题
– 集群问题
– 容灾问题
问题解决流程：
1. 问题识别
– 确认问题现象
– 收集问题信息
– 确定问题影响范围
2. 问题分析
– 分析问题原因
– 评估问题严重程度
– 制定解决计划
3. 解决方案实施
– 执行解决方案
– 监控解决过程
– 验证解决效果
4. 问题关闭
– 确认问题解决
– 记录解决方案
– 总结经验教训
5. 预防措施
– 分析问题根源
– 制定预防措施
– 更新相关文档
- 重复性：同一类型的问题可能在不同环境中重复出现
- 多样性：问题类型多样，涉及数据库的各个方面
- 关联性：某些问题可能与其他问题相关联
- 时效性：随着版本更新，问题可能会变化
1.2 问题分类与分析方法
1.2.1 问题分类
问题分类：
1. 安装配置类问题
– 安装失败
– 配置错误
– 启动失败
– 连接问题
2. 日常维护类问题
– 空间不足
– 索引问题
– 统计信息问题
– 日志管理问题
3. 备份恢复类问题
– 备份失败
– 恢复失败
– 备份策略问题
– 灾备问题
4. 性能优化类问题
– 慢查询
– 连接数过高
– I/O性能差
– 内存不足
5. 安全管理类问题
– 权限问题
– 访问控制问题
– 审计问题
– 数据安全问题
6. 高可用类问题
– 复制问题
– 故障切换问题
– 集群问题
– 容灾问题
1.2.2 问题分析方法
- 日志分析：查看数据库日志、操作系统日志等，了解问题发生的时间和原因
- 监控数据：分析监控系统收集的数据，了解系统状态
- 问题复现：尝试复现问题，了解问题的具体表现
- 环境检查：检查系统环境、配置参数等，寻找问题线索
- 经验判断：基于以往经验，判断可能的问题原因
- 专家咨询：向技术专家或厂商寻求帮助
1.3 问题解决流程
1.3.1 问题解决步骤
问题解决流程：
1. 问题识别
– 确认问题现象
– 收集问题信息
– 确定问题影响范围
2. 问题分析
– 分析问题原因
– 评估问题严重程度
– 制定解决计划
3. 解决方案实施
– 执行解决方案
– 监控解决过程
– 验证解决效果
4. 问题关闭
– 确认问题解决
– 记录解决方案
– 总结经验教训
5. 预防措施
– 分析问题根源
– 制定预防措施
– 更新相关文档
1.3.2 问题记录与管理
- 问题记录：详细记录问题现象、原因、解决方案等信息
- 知识库：建立问题知识库，积累解决方案
- 趋势分析：分析问题发生的趋势，预防类似问题
- 持续改进：基于问题解决经验，改进系统和流程
Part02-生产环境规划与建议
2.1 安装配置常见问题
1. 安装过程中提示权限不足，如何解决？
问题现象：安装过程中出现”Permission denied”或权限相关错误。
原因分析：安装用户没有足够的权限创建目录或文件。
解决方案：
- 使用root用户或具有sudo权限的用户执行安装
- 确保安装路径存在且有足够的权限
- 检查文件系统权限设置
2. 数据库启动失败，提示找不到配置文件，如何解决？
问题现象：启动数据库时提示”could not find configuration file”。
原因分析：配置文件路径错误或配置文件不存在。
解决方案：
- 检查数据库数据目录是否正确
- 确认配置文件是否存在于正确的位置
- 使用-c参数指定配置文件路径
3. 数据库连接失败，提示”connection refused”，如何解决？
问题现象：连接数据库时提示”connection refused”或”connection timed out”。
原因分析：数据库未启动、监听未配置或网络问题。
解决方案：
- 检查数据库是否运行：
sys_ctl status -D /kingbase/fgdata - 检查监听是否配置：
netstat -tulpn | grep 54321 - 检查防火墙设置：
iptables -L - 检查网络连接：
ping 192.168.1.100，风哥提示：
4. 安装后无法登录数据库，提示密码错误，如何解决？
问题现象：使用安装时设置的密码登录数据库，提示密码错误。
原因分析：密码设置错误或密码文件权限问题。
解决方案：
- 重置系统密码：修改pg_hba.conf文件，使用trust认证方式，然后重启数据库，修改密码后再改回原认证方式
- 检查密码文件权限：确保密码文件权限正确
2.2 日常维护常见问题
1. 表空间空间不足，如何解决？
问题现象：数据库操作时提示”no space left on device”或表空间使用率接近100%。
原因分析：表空间所在磁盘空间不足或数据增长过快。
解决方案：
- 清理无用数据：删除过期数据或归档数据
- 扩展表空间：添加新的磁盘分区到表空间
- 监控数据增长：建立数据增长监控机制，提前预警
2. 索引失效或性能下降，如何解决？
问题现象：查询性能下降，执行计划显示未使用索引。
原因分析：索引碎片化、统计信息过期或索引设计不合理。
解决方案：
- 重建索引：
REINDEX INDEX idx_fgedu_user_age; - 更新统计信息：
ANALYZE fgedu_user; - 检查索引设计：根据查询模式优化索引
3. 数据库日志过大，如何管理？
问题现象：数据库日志文件过大，占用大量磁盘空间。
原因分析：日志级别设置过高或日志清理策略未配置。
解决方案：
- 调整日志级别：
ALTER SYSTEM SET log_min_messages = 'warning'; - 配置日志轮转：设置log_rotation_age和log_rotation_size参数
- 定期清理日志：使用脚本定期清理过期日志
4. 数据库连接数过高，如何解决？
问题现象：数据库连接数达到上限，新连接被拒绝。
原因分析：应用程序未正确关闭连接或连接池配置不合理。
解决方案：
- 调整最大连接数：
ALTER SYSTEM SET max_connections = '200'; - 检查连接泄漏：分析应用程序代码，确保连接正确关闭
- 优化连接池配置：调整连接池大小和超时设置
2.3 备份恢复常见问题
1. 备份失败，提示权限不足，如何解决？
问题现象：执行备份时提示”permission denied”或无法写入备份文件。，学习交流加群风哥微信: itpux-com
原因分析：备份用户没有足够的权限或备份目录不存在。
解决方案：
- 确保备份目录存在且有足够的权限：
mkdir -p /kingbase/backup && chown kingbase:kingbase /kingbase/backup - 使用具有足够权限的用户执行备份
- 检查文件系统权限设置
2. 恢复失败，提示备份文件损坏，如何解决？
问题现象：执行恢复时提示”backup file corrupted”或无法读取备份文件。
原因分析：备份文件损坏或备份过程中断。
解决方案：
- 使用验证过的备份文件：定期验证备份的完整性
- 检查备份过程：确保备份过程正常完成
- 使用多个备份：保留多个备份版本，以防单个备份损坏
3. 恢复时间过长，如何优化？
问题现象：数据库恢复过程耗时过长，影响业务恢复。
原因分析：备份文件过大、I/O性能差或恢复参数配置不合理。
解决方案：
- 使用增量备份：减少备份文件大小
- 优化存储性能：使用SSD存储
- 调整恢复参数：如wal_buffers、checkpoint_completion_target等
- 并行恢复：使用多个进程进行恢复
4. 灾备系统数据不同步，如何解决？
问题现象：主备数据库数据不一致，或复制延迟过大。
原因分析：网络问题、主库负载过高或复制配置不合理。
解决方案：
- 检查网络连接：确保网络稳定，延迟低
- 监控复制状态：
SELECT * FROM sys_stat_replication; - 调整复制参数：如synchronous_commit、wal_sender_timeout等
- 优化主库性能：减少主库负载，提高复制效率
Part03-生产环境项目实施方案
3.1 性能优化常见问题
1. SQL执行缓慢，如何优化？
问题现象：SQL语句执行时间长，影响应用响应速度。
原因分析：SQL语句编写不合理、缺少索引或执行计划不佳。
解决方案：
- 分析执行计划：
EXPLAIN ANALYZE SELECT * FROM fgedu_user WHERE age > 30;，学习交流加群风哥QQ113257174 - 优化SQL语句：避免使用SELECT *，合理使用WHERE子句
- 创建合适的索引：
CREATE INDEX idx_fgedu_user_age ON fgedu_user(age); - 更新统计信息：
ANALYZE fgedu_user;
2. 数据库CPU使用率高，如何解决？
问题现象：数据库服务器CPU使用率持续过高，系统响应缓慢。
原因分析：SQL语句执行效率低、并发连接数过高或系统资源不足。
解决方案：
- 查找消耗CPU的SQL：
SELECT pid, usename, query_start, state, query FROM pg_stat_activity WHERE state = 'active' ORDER BY query_start; - 优化SQL语句：减少复杂查询，使用索引
- 调整并发参数：如max_connections、work_mem等
- 增加CPU资源：升级服务器硬件
3. 数据库I/O性能差，如何优化？
问题现象：数据库I/O等待时间长，系统响应缓慢。
原因分析：存储性能差、SQL语句I/O密集或数据库参数配置不合理。
解决方案：
- 使用SSD存储：提高I/O性能
- 优化SQL语句：减少全表扫描，使用索引
- 调整I/O参数：如random_page_cost、effective_io_concurrency等
- 使用RAID 10：提高存储性能和可靠性
4. 数据库内存使用过高，如何优化？
问题现象：数据库内存使用率高，系统出现内存不足警告。
原因分析：内存参数配置不合理、连接数过高或查询结果集过大。
解决方案：
- 调整内存参数：如shared_buffers、work_mem等
- 限制连接数：调整max_connections参数
- 优化查询：减少结果集大小，使用分页查询
- 增加内存资源：升级服务器内存
3.2 安全管理常见问题
1. 用户权限过大，如何管理？
问题现象：用户拥有过多权限，存在安全风险。
原因分析：权限管理不当，未遵循最小权限原则。
解决方案：
- 审查用户权限：
SELECT * FROM sys_roles; - 回收不必要的权限：
REVOKE ALL PRIVILEGES ON fgedu_user FROM fgedu;，更多视频教程www.fgedu.net.cn - 使用角色管理：创建角色并赋予适当的权限
- 定期权限审计：建立权限审计机制
2. 数据库被未授权访问，如何防范？
问题现象：发现未授权用户访问数据库的记录。
原因分析：密码泄露、网络访问控制不当或安全配置薄弱。
解决方案：
- 修改用户密码：
ALTER USER fgedu WITH PASSWORD 'new_password'; - 配置防火墙：限制数据库服务器的网络访问
- 启用SSL加密：
ALTER SYSTEM SET ssl = 'on'; - 开启审计功能：
ALTER SYSTEM SET audit_enabled = 'on';
3. 审计日志未记录或记录不完整，如何解决？
问题现象：审计日志未记录操作或记录不完整。
原因分析：审计功能未开启或审计配置不当。
解决方案：
- 开启审计功能：
ALTER SYSTEM SET audit_enabled = 'on'; - 配置审计级别：
ALTER SYSTEM SET audit_level = 'MEDIUM'; - 配置审计存储：
ALTER SYSTEM SET audit_store = 'file'; - 检查审计日志：
SELECT * FROM sys_audit_log;
4. 数据泄露风险，如何防范？
问题现象：存在数据泄露的风险，如敏感数据未加密。
原因分析：数据传输或存储未加密，权限管理不当。
解决方案：
- 启用SSL加密：保护数据传输
- 使用透明数据加密(TDE)：保护数据存储
- 对敏感数据进行加密：使用加密函数
- 加强权限管理：限制敏感数据的访问
3.3 高可用常见问题
1. 主备复制中断，如何恢复？
问题现象：主备复制中断，备库无法同步主库数据。
原因分析：网络问题、主库故障或复制配置错误。
解决方案：
- 检查网络连接：确保主备之间网络畅通
- 检查主库状态：确保主库正常运行
- 检查复制状态：
SELECT * FROM sys_stat_replication;，更多学习教程公众号风哥教程itpux_com - 重新配置复制：如果复制配置错误，重新配置
2. 故障切换失败，如何处理？
问题现象：主库故障时，自动故障切换失败。
原因分析：故障检测机制故障、网络问题或配置错误。
解决方案：
- 手动切换：使用
sys_ctl promote命令手动提升备库 - 检查故障检测配置：确保故障检测参数配置正确
- 检查网络连接：确保集群节点之间网络畅通
- 测试故障切换：定期进行故障切换测试
3. 集群节点无法加入，如何解决？
问题现象：新节点无法加入集群，或现有节点无法重新加入集群。
原因分析：网络问题、配置错误或节点状态不一致。
解决方案：
- 检查网络连接：确保节点之间网络畅通
- 检查配置文件：确保集群配置正确
- 同步节点状态：使用基础备份同步节点数据
- 检查节点状态：
SELECT * FROM sys_stat_cluster;
4. 容灾系统无法切换，如何处理？
# 安装过程中的错误信息
Error: Could not create directory /kingbase/app: Permission denied
# 检查目录权限
$ ls -la /kingbase/
total 16
drwxr-xr-x 3 root root 4096 Jan 15 14:00 .
drwxr-xr-x 20 root root 4096 Jan 15 13:50 ..
drwxr-xr-x 2 root root 4096 Jan 15 14:00 backup
# 原因分析：/kingbase目录属于root用户，安装用户kingbase没有写权限
# 解决方案
# 1. 修改目录权限
$ chown -R kingbase:kingbase /kingbase/
# 2. 重新安装
$ su – kingbase
$ cd /tmp
$ unzip KingbaseES_V8R6_*.zip
$ cd KingbaseES_V8R6_*
$ ./setup.sh
# 3. 验证安装
$ sys_ctl status -D /kingbase/fgdata
pg_ctl: server is running (PID: 12345)
/kingbase/app/bin/postmaster “-D” “/kingbase/fgdata”
# 4. 测试连接
$ psql -h fgedu.localhost -p 54321 -U system -d fgedudb
Password for user system:
psql (KingbaseES V8R6)
Type “help” for help.
fgedudb=# \l
List of databases
Name | Owner | Encoding | Collate | Ctype | Access privileges
———–+———-+———-+———+——-+———————–
fgedudb | system | UTF8 | C | C |
security | system | UTF8 | C | C |
template0 | system | UTF8 | C | C | =c/system +
| | | | | system=CTc/system
template1 | system | UTF8 | C | C | =c/system +
| | | | | system=CTc/system
(4 rows)
# 问题分析
# 1. 查看系统负载
$ top
top – 14:30:00 up 10 days, 2:15, 2 users, load average: 2.50, 2.45, 2.40
Tasks: 320 total, 5 running, 315 sleeping, 0 stopped, 0 zombie
%Cpu(s): 50.0 us, 10.0 sy, 0.0 ni, 40.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 65971436 total, 15971436 free, 45000000 used, 5000000 buff/cache
KiB Swap: 8388604 total, 8388604 free, 0 used. 15215848 avail Mem
# 2. 查看慢查询
$ psql -h fgedu.localhost -p 54321 -U system -d fgedudb -c “SELECT pid, usename, query_start, state, query FROM pg_stat_activity WHERE state = ‘active’ ORDER BY query_start;”
pid | usename | query_start | state | query
——-+———+——————————-+——–+—————————————————
12345 | fgedu | 2024-01-15 14:28:30.123456+08 | active | SELECT * FROM fgedu_order WHERE order_date > ‘2024-01-01’ ORDER BY order_id
# 3. 分析执行计划
$ psql -h fgedu.localhost -p 54321 -U system -d fgedudb -c “EXPLAIN ANALYZE SELECT * FROM fgedu_order WHERE order_date > ‘2024-01-01’ ORDER BY order_id;”
QUERY PLAN
———————————————————————————————–
Sort (cost=10000000000.00..10000000000.26 rows=10000 width=100) (actual time=100.100..100.105 rows=10000 loops=1)
Sort Key: order_id
Sort Method: quicksort Memory: 25kB
-> Seq Scan on fgedu_order (cost=10000000000.00..10000000000.10 rows=10000 width=100) (actual time=0.010..50.030 rows=10000 loops=1)
Filter: (order_date > ‘2024-01-01’::date)
Rows Removed by Filter: 90000
Planning Time: 0.050 ms
Execution Time: 100.120 ms
# 4. 检查索引
$ psql -h fgedu.localhost -p 54321 -U system -d fgedudb -c “SELECT relname, indexrelname FROM pg_stat_user_indexes WHERE relname = ‘fgedu_order’;”
relname | indexrelname
————+————–
fgedu_order | fgedu_order_pkey
# 原因分析：fgedu_order表没有为order_date列创建索引，导致全表扫描
# 解决方案
# 1. 创建索引
$ psql -h fgedu.localhost -p 54321 -U system -d fgedudb -c “CREATE INDEX idx_fgedu_order_date ON fgedu_order(order_date);”
CREATE INDEX
# 2. 分析执行计划
$ psql -h fgedu.localhost -p 54321 -U system -d fgedudb -c “EXPLAIN ANALYZE SELECT * FROM fgedu_order WHERE order_date > ‘2024-01-01’ ORDER BY order_id;”
QUERY PLAN
—————————————————————————————————
Sort (cost=10000000000.26..10000000000.51 rows=10000 width=100) (actual time=20.050..20.055 rows=10000 loops=1)
Sort Key: order_id
Sort Method: quicksort Memory: 25kB
-> Bitmap Heap Scan on fgedu_order (cost=10000000000.00..10000000000.10 rows=10000 width=100) (actual time=0.010..10.020 rows=10000 loops=1)
Recheck Cond: (order_date > ‘2024-01-01’::date)
Heap Blocks: exact=50
-> Bitmap Index Scan on idx_fgedu_order_date (cost=10000000000.00..10000000000.00 rows=10000 width=0) (actual time=0.005..0.005 rows=10000 loops=1)
Index Cond: (order_date > ‘2024-01-01’::date)
Planning Time: 0.080 ms
Execution Time: 20.070 ms
# 3. 验证性能
$ psql -h fgedu.localhost -p 54321 -U system -d fgedudb -c “SELECT count(*) FROM fgedu_order WHERE order_date > ‘2024-01-01’;”
count
——-
10000
(1 row)
# 执行时间：20ms，比优化前的100ms提高了80%
# 问题分析
# 1. 尝试启动数据库
$ sys_ctl start -D /kingbase/fgdata
pg_ctl: another server might be running; trying to start server anyway
waiting for server to start….2024-01-15 14:30:00 GMT [12345]: [1-1] ERROR: could not open file “global/pg_control”: No such file or directory
2024-01-15 14:30:00 GMT [12345]: [2-1] FATAL: could not open control file “global/pg_control”: No such file or directory
stopped waiting
pg_ctl: could not start server
Examine the log output.
# 2. 检查控制文件
$ ls -la /kingbase/fgdata/global/
total 16
drwx—— 2 kingbase kingbase 4096 Jan 15 14:29 .
drwx—— 19 kingbase kingbase 4096 Jan 15 14:29 ..
-rw——- 1 kingbase kingbase 0 Jan 15 14:29 pg_control
# 3. 检查最近的备份
$ ls -la /kingbase/backup/
total 1024000
drwxr-xr-x 2 kingbase kingbase 4096 Jan 15 14:00 .
drwxr-xr-x 5 kingbase kingbase 4096 Jan 15 13:50 ..
-rw-r–r– 1 kingbase kingbase 1048576000 Jan 15 14:00 fgedudb_20240115_140000.backup
# 原因分析：控制文件损坏，需要从备份中恢复
# 解决方案
# 1. 停止数据库
$ sys_ctl stop -D /kingbase/fgdata
# 2. 从备份中恢复控制文件
$ krestore -U system -d fgedudb -f /kingbase/backup/fgedudb_20240115_140000.backup –restore-control-file
# 3. 启动数据库到恢复模式
$ sys_ctl start -D /kingbase/fgdata -m recovery
# 4. 执行恢复
$ psql -h fgedu.localhost -p 54321 -U system -d fgedudb -c “SELECT pg_wal_replay_resume();”
pg_wal_replay_resume
——————–
(1 row)
# 5. 验证数据库
$ sys_ctl status -D /kingbase/fgdata
pg_ctl: server is running (PID: 12345)
/kingbase/app/bin/postmaster “-D” “/kingbase/fgdata”
$ psql -h fgedu.localhost -p 54321 -U system -d fgedudb
Password for user system:
psql (KingbaseES V8R6)
Type “help” for help.
fgedudb=# \l
List of databases
Name | Owner | Encoding | Collate | Ctype | Access privileges
———–+———-+———-+———+——-+———————–
fgedudb | system | UTF8 | C | C |
security | system | UTF8 | C | C |
template0 | system | UTF8 | C | C | =c/system +
| | | | | system=CTc/system
template1 | system | UTF8 | C | C | =c/system +
| | | | | system=CTc/system
(4 rows)
# 6. 检查数据完整性
$ psql -h fgedu.localhost -p 54321 -U system -d fgedudb -c “SELECT count(*) FROM fgedu_user;”
count
——-
1000
(1 row)
问题现象：主数据中心故障时，容灾系统无法正常切换。
原因分析：容灾配置错误、数据不同步或切换流程不当。
解决方案：
- 检查容灾配置：确保容灾系统配置正确
- 检查数据同步状态：确保容灾系统数据与主系统一致
- 执行切换演练：定期进行容灾切换演练
- 制定详细的切换流程：确保切换过程有序进行
Part04-生产案例与实战讲解
4.1 安装配置案例
4.1.1 案例背景
某企业在安装金仓数据库V8R6时，遇到了权限不足的问题，导致安装失败。
4.1.2 问题分析
# 安装过程中的错误信息
Error: Could not create directory /kingbase/app: Permission denied
# 检查目录权限
$ ls -la /kingbase/
total 16
drwxr-xr-x 3 root root 4096 Jan 15 14:00 .
drwxr-xr-x 20 root root 4096 Jan 15 13:50 ..
drwxr-xr-x 2 root root 4096 Jan 15 14:00 backup
# 原因分析：/kingbase目录属于root用户，安装用户kingbase没有写权限
4.1.3 解决方案
# 解决方案
# 1. 修改目录权限
$ chown -R kingbase:kingbase /kingbase/
# 2. 重新安装
$ su – kingbase
$ cd /tmp
$ unzip KingbaseES_V8R6_*.zip
$ cd KingbaseES_V8R6_*
$ ./setup.sh
# 3. 验证安装
$ sys_ctl status -D /kingbase/fgdata
pg_ctl: server is running (PID: 12345)
/kingbase/app/bin/postmaster “-D” “/kingbase/fgdata”
# 4. 测试连接
$ psql -h fgedu.localhost -p 54321 -U system -d fgedudb
Password for user system:
psql (KingbaseES V8R6)
Type “help” for help.
fgedudb=# \l
List of databases
Name | Owner | Encoding | Collate | Ctype | Access privileges
———–+———-+———-+———+——-+———————–
fgedudb | system | UTF8 | C | C |
security | system | UTF8 | C | C |
template0 | system | UTF8 | C | C | =c/system +
| | | | | system=CTc/system
template1 | system | UTF8 | C | C | =c/system +
| | | | | system=CTc/system
(4 rows)
4.2 性能优化案例
4.2.1 案例背景
某企业金仓数据库系统在业务高峰期出现性能下降，SQL执行时间从正常的50ms增加到200ms以上。
4.2.2 问题分析
# 问题分析
# 1. 查看系统负载
$ top
top – 14:30:00 up 10 days, 2:15, 2 users, load average: 2.50, 2.45, 2.40
Tasks: 320 total, 5 running, 315 sleeping, 0 stopped, 0 zombie
%Cpu(s): 50.0 us, 10.0 sy, 0.0 ni, 40.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 65971436 total, 15971436 free, 45000000 used, 5000000 buff/cache
KiB Swap: 8388604 total, 8388604 free, 0 used. 15215848 avail Mem
# 2. 查看慢查询
$ psql -h fgedu.localhost -p 54321 -U system -d fgedudb -c “SELECT pid, usename, query_start, state, query FROM pg_stat_activity WHERE state = ‘active’ ORDER BY query_start;”
pid | usename | query_start | state | query
——-+———+——————————-+——–+—————————————————
12345 | fgedu | 2024-01-15 14:28:30.123456+08 | active | SELECT * FROM fgedu_order WHERE order_date > ‘2024-01-01’ ORDER BY order_id
# 3. 分析执行计划
$ psql -h fgedu.localhost -p 54321 -U system -d fgedudb -c “EXPLAIN ANALYZE SELECT * FROM fgedu_order WHERE order_date > ‘2024-01-01’ ORDER BY order_id;”
QUERY PLAN
———————————————————————————————–
Sort (cost=10000000000.00..10000000000.26 rows=10000 width=100) (actual time=100.100..100.105 rows=10000 loops=1)
Sort Key: order_id
Sort Method: quicksort Memory: 25kB
-> Seq Scan on fgedu_order (cost=10000000000.00..10000000000.10 rows=10000 width=100) (actual time=0.010..50.030 rows=10000 loops=1)
Filter: (order_date > ‘2024-01-01’::date)
Rows Removed by Filter: 90000
Planning Time: 0.050 ms
Execution Time: 100.120 ms
# 4. 检查索引
$ psql -h fgedu.localhost -p 54321 -U system -d fgedudb -c “SELECT relname, indexrelname FROM pg_stat_user_indexes WHERE relname = ‘fgedu_order’;”
relname | indexrelname
————+————–
fgedu_order | fgedu_order_pkey
# 原因分析：fgedu_order表没有为order_date列创建索引，导致全表扫描
4.2.3 解决方案
# 解决方案
# 1. 创建索引
$ psql -h fgedu.localhost -p 54321 -U system -d fgedudb -c “CREATE INDEX idx_fgedu_order_date ON fgedu_order(order_date);”
CREATE INDEX
# 2. 分析执行计划
$ psql -h fgedu.localhost -p 54321 -U system -d fgedudb -c “EXPLAIN ANALYZE SELECT * FROM fgedu_order WHERE order_date > ‘2024-01-01’ ORDER BY order_id;”
QUERY PLAN
—————————————————————————————————
Sort (cost=10000000000.26..10000000000.51 rows=10000 width=100) (actual time=20.050..20.055 rows=10000 loops=1)
Sort Key: order_id
Sort Method: quicksort Memory: 25kB
-> Bitmap Heap Scan on fgedu_order (cost=10000000000.00..10000000000.10 rows=10000 width=100) (actual time=0.010..10.020 rows=10000 loops=1)
Recheck Cond: (order_date > ‘2024-01-01’::date)
Heap Blocks: exact=50
-> Bitmap Index Scan on idx_fgedu_order_date (cost=10000000000.00..10000000000.00 rows=10000 width=0) (actual time=0.005..0.005 rows=10000 loops=1)
Index Cond: (order_date > ‘2024-01-01’::date)
Planning Time: 0.080 ms
Execution Time: 20.070 ms
# 3. 验证性能
$ psql -h fgedu.localhost -p 54321 -U system -d fgedudb -c “SELECT count(*) FROM fgedu_order WHERE order_date > ‘2024-01-01’;”
count
——-
10000
(1 row)
# 执行时间：20ms，比优化前的100ms提高了80%
4.3 故障处理案例
4.3.1 案例背景
某企业金仓数据库系统在运行过程中突然崩溃，无法启动，提示控制文件损坏。
4.3.2 问题分析
# 问题分析
# 1. 尝试启动数据库
$ sys_ctl start -D /kingbase/fgdata
pg_ctl: another server might be running; trying to start server anyway
waiting for server to start….2024-01-15 14:30:00 GMT [12345]: [1-1] ERROR: could not open file “global/pg_control”: No such file or directory
2024-01-15 14:30:00 GMT [12345]: [2-1] FATAL: could not open control file “global/pg_control”: No such file or directory
stopped waiting
pg_ctl: could not start server
Examine the log output.
# 2. 检查控制文件
$ ls -la /kingbase/fgdata/global/
total 16
drwx—— 2 kingbase kingbase 4096 Jan 15 14:29 .
drwx—— 19 kingbase kingbase 4096 Jan 15 14:29 ..
-rw——- 1 kingbase kingbase 0 Jan 15 14:29 pg_control
# 3. 检查最近的备份
$ ls -la /kingbase/backup/
total 1024000
drwxr-xr-x 2 kingbase kingbase 4096 Jan 15 14:00 .
drwxr-xr-x 5 kingbase kingbase 4096 Jan 15 13:50 ..
-rw-r–r– 1 kingbase kingbase 1048576000 Jan 15 14:00 fgedudb_20240115_140000.backup
# 原因分析：控制文件损坏，需要从备份中恢复
4.3.3 解决方案
# 解决方案
# 1. 停止数据库
$ sys_ctl stop -D /kingbase/fgdata
# 2. 从备份中恢复控制文件
$ krestore -U system -d fgedudb -f /kingbase/backup/fgedudb_20240115_140000.backup –restore-control-file
# 3. 启动数据库到恢复模式
$ sys_ctl start -D /kingbase/fgdata -m recovery
# 4. 执行恢复
$ psql -h fgedu.localhost -p 54321 -U system -d fgedudb -c “SELECT pg_wal_replay_resume();”
pg_wal_replay_resume
——————–
(1 row)
# 5. 验证数据库
$ sys_ctl status -D /kingbase/fgdata
pg_ctl: server is running (PID: 12345)
/kingbase/app/bin/postmaster “-D” “/kingbase/fgdata”
$ psql -h fgedu.localhost -p 54321 -U system -d fgedudb
Password for user system:
psql (KingbaseES V8R6)
Type “help” for help.
fgedudb=# \l
List of databases
Name | Owner | Encoding | Collate | Ctype | Access privileges
———–+———-+———-+———+——-+———————–
fgedudb | system | UTF8 | C | C |
security | system | UTF8 | C | C |
template0 | system | UTF8 | C | C | =c/system +
| | | | | system=CTc/system
template1 | system | UTF8 | C | C | =c/system +
| | | | | system=CTc/system
(4 rows)
# 6. 检查数据完整性
$ psql -h fgedu.localhost -p 54321 -U system -d fgedudb -c “SELECT count(*) FROM fgedu_user;”
count
——-
1000
(1 row)
Part05-风哥经验总结与分享
5.1 常见问题总结
5.1.1 安装配置问题
- 权限问题：安装用户权限不足，导致安装失败
- 路径问题：安装路径不存在或权限不足
- 端口问题：端口被占用，导致数据库无法启动
- 配置问题：配置文件错误，导致数据库无法启动或连接
5.1.2 日常维护问题
日常维护常见问题：
安装配置预防措施：
1. 安装前准备
– 检查硬件和软件要求
– 准备足够的磁盘空间
– 确保安装用户有足够的权限
– 规划好安装路径和数据路径
2. 配置优化
– 风哥教程参考官方文档进行参数配置
– 根据系统特点调整参数
– 定期检查配置文件
3. 安全配置
– 配置防火墙规则
– 设置强密码策略
– 启用SSL加密
– 限制网络访问
4. 测试验证
– 安装后进行全面测试
– 验证数据库连接和功能
– 检查系统日志
- 空间问题：表空间空间不足，需要清理或扩容，from DB视频:www.itpux.com
- 索引问题：索引碎片化或设计不合理，导致性能下降
- 统计信息问题：统计信息过期，导致执行计划不佳
- 连接问题：连接数过高或连接泄漏，导致系统资源耗尽
- 日志问题：日志过大或管理不当，占用磁盘空间
5.1.3 备份恢复问题
- 备份失败：权限不足、空间不足或网络问题
- 恢复失败：备份文件损坏或恢复参数错误
- 复制问题：主备复制中断或延迟过大
- 灾备问题：灾备系统数据不同步或切换失败
5.1.4 性能优化问题
- SQL问题：SQL语句编写不合理，导致执行缓慢
- 索引问题：缺少索引或索引设计不合理
- 参数问题：数据库参数配置不合理，影响性能
- 资源问题：系统资源不足，如CPU、内存、I/O
5.1.5 安全管理问题
- 权限问题：用户权限过大或管理不当
- 访问问题：网络访问控制不当，存在安全风险
- 审计问题：审计功能未开启或配置不当
- 数据问题：敏感数据未加密，存在泄露风险
5.2 问题预防措施
5.2.1 安装配置预防
安装配置预防措施：
1. 安装前准备
– 检查硬件和软件要求
– 准备足够的磁盘空间
– 确保安装用户有足够的权限
– 规划好安装路径和数据路径
2. 配置优化
– 风哥教程参考官方文档进行参数配置
– 根据系统特点调整参数
– 定期检查配置文件
3. 安全配置
– 配置防火墙规则
– 设置强密码策略
– 启用SSL加密
– 限制网络访问
4. 测试验证
– 安装后进行全面测试
– 验证数据库连接和功能
– 检查系统日志
5.2.2 日常维护预防
- 监控体系：建立完善的监控体系，及时发现问题
- 定期检查：定期检查系统状态、空间使用、索引状态等
- 自动化脚本：开发自动化脚本，定期执行维护任务
- 备份策略：制定合理的备份策略，定期备份和验证
- 补丁管理：及时安装安全补丁和版本更新
5.2.3 性能优化预防
- SQL优化：建立SQL审核机制，优化SQL语句
- 索引管理：定期检查和优化索引
- 参数调优：根据系统负载调整参数
- 资源监控：监控系统资源使用情况，及时扩容
- 性能测试：定期进行性能测试，发现瓶颈
5.2.4 安全管理预防
- 权限管理：遵循最小权限原则，定期审查权限
- 访问控制：限制网络访问，使用VPN等安全通道
- 审计日志：开启审计功能，定期审查审计日志
- 数据加密：对敏感数据进行加密处理
- 安全审计：定期进行安全审计，发现安全隐患
5.3 故障处理经验
5.3.1 故障处理原则
故障处理原则：
- 保持冷静：遇到故障时保持冷静，避免慌乱
- 快速响应：及时响应故障，减少业务影响
- 准确诊断：通过日志和监控数据准确诊断问题
- 安全恢复：确保恢复过程安全，避免数据丢失
- 记录总结：详细记录故障处理过程，总结经验教训
5.3.2 故障处理技巧
- 日志分析：仔细分析数据库日志和操作系统日志
- 隔离问题：逐步隔离问题，缩小故障范围
- 测试验证：在测试环境验证解决方案
- 回滚方案：准备回滚方案，以防解决方案失败
- 沟通协调：及时与相关人员沟通，协调解决
5.3.3 经验总结
- 预防为主：建立完善的预防机制，减少故障发生
- 快速响应：建立故障响应机制，及时处理故障
- 持续改进：基于故障处理经验，持续改进系统和流程
- 知识共享：建立知识库，分享故障处理经验
- 团队协作：加强团队协作，提高故障处理效率
风哥提示：金仓数据库的常见问题与解答是DBA人员的重要参考资料，了解这些问题的原因和解决方案，可以帮助我们更快地解决问题，减少系统 downtime。在实际工作中，我们应该建立完善的监控体系和预防机制，定期进行系统维护和优化，以减少故障的发生。同时，我们应该不断学习和总结经验，提高故障处理能力。
通过本文档的学习，您应该掌握了金仓数据库的常见问题与解答，包括安装配置、日常维护、备份恢复、性能优化、安全管理等方面的常见问题。在实际工作中，您可以参考这些解答，快速解决遇到的问题，确保数据库系统的稳定运行。
本文档风哥教程参考金仓官方文档常见问题解答、系统管理员手册等内容，结合实际生产经验编写，希望对您的工作有所帮助。
本文由风哥教程整理发布,仅用于学习测试使用,转载注明出处:http://www.fgedu.net.cn/10327.html
联系我们
在线咨询：
微信号：itpux-com
工作日：9:30-18:30，节假日休息