印刻数据库

外观

DB2 故障分类与处理 ​

故障分类概述 ​

DB2数据库故障是指数据库系统在运行过程中出现的异常情况，导致数据库服务不可用、数据丢失或性能严重下降。故障分类是数据库管理员（DBA）进行故障诊断和恢复的基础，合理的故障分类有助于快速定位问题根源并采取有效的恢复措施。

故障分类的重要性 ​

  • 帮助DBA快速识别故障类型和影响范围
  • 指导DBA选择合适的诊断工具和方法
  • 确定故障恢复的优先级和策略
  • 为制定预防措施提供依据
  • 便于故障统计和分析，改进系统可靠性

故障分类原则 ​

  • 影响范围：根据故障影响的数据库范围分类
  • 故障原因：根据故障发生的根本原因分类
  • 故障性质：根据故障的严重程度和恢复难度分类
  • 故障时间：根据故障发生的时间和持续时间分类

按影响范围分类 ​

1. 实例级故障 ​

实例级故障影响整个DB2实例，导致实例下的所有数据库不可用。

故障类型 ​

  • 实例崩溃：DB2实例进程意外终止
  • 实例挂起：实例进程运行但无法响应请求
  • 实例配置错误：错误的实例参数设置导致实例无法启动
  • 内存不足：实例内存耗尽导致实例崩溃
  • CPU资源耗尽：实例进程占用过多CPU资源，导致实例响应缓慢或无响应

诊断方法 ​

bash
# 检查实例状态
db2ilist
db2start
db2 get instance

# 查看实例日志
db2diag -g instance=db2inst1 -l ERROR

# 检查操作系统资源
top -p $(pgrep -f db2sysc)
free -m
df -h

恢复策略 ​

  1. 重启DB2实例：db2stop force; db2start
  2. 检查并修复实例配置：db2 get dbm cfg; db2 update dbm cfg using parameter value
  3. 调整资源限制：增加实例内存、调整CPU调度策略
  4. 分析故障日志，识别根本原因
  5. 实施预防措施，防止类似故障再次发生

2. 数据库级故障 ​

数据库级故障影响单个或多个数据库，导致受影响的数据库不可用。

故障类型 ​

  • 数据库崩溃：数据库进程意外终止
  • 数据库挂起：数据库进程运行但无法响应请求
  • 数据库配置错误：错误的数据库参数设置导致数据库无法启动
  • 日志文件损坏：事务日志文件损坏导致数据库无法恢复
  • 系统表损坏：系统目录表损坏导致数据库无法正常运行

诊断方法 ​

bash
# 检查数据库状态
db2 list db directory
db2 connect to sample
db2 list applications for db sample

# 查看数据库日志
db2diag -g database=sample -l ERROR

# 检查数据库一致性
db2dart sample /DB

# 检查数据库配置
db2 get db cfg for sample

恢复策略 ​

  1. 重启数据库：db2 deactivate db sample; db2 activate db sample
  2. 恢复数据库：RESTORE DATABASE sample FROM /db2/backup TAKEN AT 20240112143000; ROLLFORWARD DATABASE sample TO END OF LOGS AND COMPLETE
  3. 修复数据库：使用db2dart工具修复数据库页损坏
  4. 重建系统表：如果系统表损坏，可能需要重建数据库
  5. 分析故障原因，实施预防措施

3. 表空间级故障 ​

表空间级故障影响单个或多个表空间，导致受影响的表空间不可用，但数据库的其他部分仍可正常运行。

故障类型 ​

  • 表空间损坏：表空间容器损坏或文件系统错误
  • 表空间离线：表空间被意外设置为离线状态
  • 表空间满：表空间空间耗尽，无法扩展
  • 容器故障：表空间的一个或多个容器不可用
  • 索引损坏：表空间中的索引损坏

诊断方法 ​

bash
# 检查表空间状态
db2 list tablespaces for db sample
db2pd -db sample -tablespaces

# 检查容器状态
db2pd -db sample -tablespaces -containers

# 检查I/O错误
db2diag -g component=IO -l ERROR

# 检查表空间一致性
db2dart sample /TS 0

恢复策略 ​

  1. 恢复表空间：RESTORE DATABASE sample TABLESPACE (userspace1) FROM /db2/backup TAKEN AT 20240112143000; ROLLFORWARD DATABASE sample TABLESPACE (userspace1) TO END OF LOGS AND COMPLETE
  2. 扩展表空间：ALTER TABLESPACE userspace1 ADD (FILE '/db2/data/userspace1_6' 1000M)
  3. 修复容器：修复或替换损坏的容器
  4. 重建索引：如果索引损坏，重建受影响的索引
  5. 分析故障原因，实施预防措施

4. 对象级故障 ​

对象级故障影响单个数据库对象（如表、索引、视图、存储过程等），导致受影响的对象不可用或性能下降。

故障类型 ​

  • 表损坏：表数据页损坏或索引损坏
  • 索引损坏：索引结构损坏导致查询失败
  • 约束违反：外键约束或唯一约束被违反
  • 对象定义错误：对象定义存在语法错误或逻辑错误
  • 权限问题：用户对对象的权限不足

诊断方法 ​

bash
# 检查对象状态
db2 describe table schema.table
db2 check index schema.index

# 检查表数据
db2 "SELECT COUNT(*) FROM schema.table"

# 检查约束
db2 "SELECT * FROM syscat.tabconst WHERE tabname = 'TABLE'"

# 检查权限
db2 "SELECT * FROM syscat.tabauth WHERE tabname = 'TABLE'"

恢复策略 ​

  1. 修复表数据：使用LOAD FROM CURSOR或IMPORT语句修复损坏的数据
  2. 重建索引：RECREATE INDEX schema.index ON schema.table (column)
  3. 修复约束：调整数据或约束定义
  4. 重新创建对象：DROP OBJECT schema.object; CREATE OBJECT schema.object (...)
  5. 调整权限：GRANT privilege ON schema.object TO user

5. 事务级故障 ​

事务级故障影响单个或多个事务，导致事务无法正常提交或回滚。

故障类型 ​

  • 死锁：两个或多个事务相互等待对方持有的锁
  • 锁超时：事务等待锁的时间超过设定的阈值
  • 事务回滚：事务执行失败导致自动回滚
  • 事务日志满：事务日志空间耗尽，无法继续执行事务
  • 长事务：事务执行时间过长，占用资源过多

诊断方法 ​

bash
# 检查锁状态
db2pd -db sample -locks -applications
db2 get snapshot for locks on sample

# 检查事务状态
db2pd -db sample -transactions
db2 get snapshot for transactions on sample

# 检查死锁日志
db2diag -g component=LOCKMGR -l ERROR

# 检查事务日志使用情况
db2 get db cfg for sample | grep -i log

恢复策略 ​

  1. 解决死锁：终止等待时间最长的事务
  2. 调整锁超时参数：UPDATE DB CFG FOR sample USING LOCKTIMEOUT 300
  3. 扩展事务日志空间：ALTER DATABASE sample ADD LOGFILE SIZE 1000
  4. 优化长事务：将长事务拆分为多个短事务
  5. 分析事务执行计划，优化SQL语句

按故障原因分类 ​

1. 硬件故障 ​

硬件故障是由硬件设备故障导致的数据库故障。

故障类型 ​

  • 磁盘故障：硬盘损坏、磁盘控制器故障
  • 内存故障：内存条损坏、内存控制器故障
  • CPU故障：CPU过热、CPU风扇故障
  • 电源故障：服务器断电、UPS故障
  • 网络故障：网卡故障、网络电缆损坏、交换机故障

诊断方法 ​

bash
# 检查磁盘状态
df -h
fsck /dev/sda1
smartctl -a /dev/sda

# 检查内存状态
free -m
memtest86+

# 检查CPU状态
top
lscpu

# 检查网络状态
ping hostname
ifconfig
netstat -an

恢复策略 ​

  1. 更换故障硬件：更换损坏的磁盘、内存、CPU等
  2. 恢复数据：从备份恢复数据或使用RAID冗余恢复
  3. 验证数据完整性：使用db2dart或db2ckbkp工具验证
  4. 实施硬件冗余：配置RAID、双电源、双网卡等
  5. 建立硬件监控机制，及时发现潜在故障

2. 软件故障 ​

软件故障是由软件程序错误导致的数据库故障。

故障类型 ​

  • DB2软件bug：DB2数据库软件本身的缺陷
  • 操作系统错误：操作系统内核错误、驱动程序故障
  • 应用程序错误：应用程序逻辑错误导致数据库故障
  • 中间件故障：中间件软件（如Web服务器、应用服务器）故障
  • 病毒或恶意软件：病毒或恶意软件攻击导致数据库故障

诊断方法 ​

bash
# 检查DB2版本和补丁级别
db2level

# 查看DB2诊断日志
db2diag -l ERROR

# 检查操作系统日志
dmesg
alert log

# 检查应用程序日志
cat /var/log/application.log

# 检查病毒扫描结果

恢复策略 ​

  1. 应用DB2补丁：db2iupdt -b /opt/ibm/db2/V11.5 -d db2inst1
  2. 更新操作系统和驱动程序：yum update; apt-get update
  3. 修复应用程序错误：调试并修复应用程序代码
  4. 隔离受感染的系统：断开网络连接，清除病毒
  5. 实施软件更新策略，定期更新软件补丁

3. 人为错误 ​

人为错误是由数据库管理员或用户的操作错误导致的数据库故障。

故障类型 ​

  • 误操作：误删除数据库对象、误执行DROP TABLE语句
  • 配置错误：错误的参数设置导致数据库性能下降或无法启动
  • 权限滥用：未经授权的用户访问或修改数据库
  • 备份恢复错误：错误的备份恢复操作导致数据丢失
  • 迁移升级错误：数据库迁移或升级过程中出现错误

诊断方法 ​

bash
# 检查操作日志
db2audit extract all from files
db2pd -db sample -transactions

# 检查配置变更
db2 get dbm cfg > current_dbm.cfg
diff current_dbm.cfg previous_dbm.cfg

# 检查备份恢复历史
db2 list history backup all for sample

# 检查数据库对象变更
db2 "SELECT * FROM syscat.tables WHERE create_time > '2024-01-12'"

恢复策略 ​

  1. 从备份恢复数据：RESTORE DATABASE sample FROM /db2/backup TAKEN AT 20240112143000
  2. 撤销错误操作：使用FLASHBACK或ROLLFORWARD命令恢复到错误操作前的状态
  3. 修复配置错误：恢复正确的配置参数
  4. 加强权限管理：实施最小权限原则，定期审查权限
  5. 建立操作规范和审批流程，减少误操作

4. 环境故障 ​

环境故障是由数据库运行环境变化导致的数据库故障。

故障类型 ​

  • 温度过高：服务器机房温度超过规定范围
  • 湿度异常：服务器机房湿度超过规定范围
  • 灰尘过多：服务器积尘导致硬件故障
  • 电磁干扰：电磁场干扰导致数据传输错误
  • 自然灾害：火灾、洪水、地震等自然灾害导致的故障

诊断方法 ​

bash
# 检查机房环境监控数据
# 查看服务器温度传感器数据
ipmitool sdr type temperature

# 检查硬件状态
lshw -short

# 检查数据完整性
db2dart sample /DB

恢复策略 ​

  1. 恢复机房环境：调整温度、湿度，清理灰尘
  2. 修复硬件故障：更换损坏的硬件设备
  3. 恢复数据：从备份恢复数据
  4. 实施环境监控：安装温湿度传感器、烟雾探测器等
  5. 制定灾难恢复计划，定期进行灾难恢复演练

按故障性质分类 ​

1. 暂时性故障 ​

暂时性故障是指可以自动恢复或通过简单操作恢复的故障，通常不会导致数据丢失。

故障类型 ​

  • 网络抖动：网络连接暂时中断
  • 资源竞争：短期的CPU、内存或I/O资源竞争
  • 锁等待：暂时的锁等待，不导致死锁
  • 临时表空间满：临时表空间空间暂时耗尽
  • 应用程序连接超时：应用程序连接数据库超时

恢复策略 ​

  1. 等待自动恢复：网络抖动、资源竞争等故障通常会自动恢复
  2. 重启应用程序：应用程序连接超时可以通过重启应用程序解决
  3. 扩展临时表空间：ALTER TABLESPACE temp1 ADD (FILE '/db2/temp/temp1_2' 1000M)
  4. 优化资源使用：调整应用程序使用资源的方式

2. 永久性故障 ​

永久性故障是指需要人工干预才能恢复的故障，可能导致数据丢失。

故障类型 ​

  • 磁盘损坏：硬盘物理损坏，无法修复
  • 数据文件损坏：数据库文件损坏，无法访问
  • 系统表损坏：系统目录表损坏，无法修复
  • 事务日志损坏：事务日志文件损坏，无法恢复
  • 硬件故障：CPU、内存等硬件设备损坏

恢复策略 ​

  1. 从备份恢复数据：RESTORE DATABASE sample FROM /db2/backup TAKEN AT 20240112143000
  2. 修复数据库对象：使用db2dart或其他工具修复损坏的数据库对象
  3. 重建数据库：如果数据库损坏严重，可能需要重建数据库
  4. 更换硬件设备：更换损坏的硬件设备

3. 灾难性故障 ​

灾难性故障是指导致整个数据库系统完全瘫痪，需要长时间恢复的严重故障。

故障类型 ​

  • 数据中心灾难：数据中心发生火灾、洪水等灾难
  • 数据库完全损坏：数据库所有数据文件和备份文件损坏
  • 恶意攻击：数据库遭受严重的恶意攻击，数据被篡改或删除
  • 大规模硬件故障：多个硬件设备同时故障，导致系统完全瘫痪

恢复策略 ​

  1. 启动灾难恢复计划：切换到灾备数据中心
  2. 从异地备份恢复数据：使用存储在异地的备份恢复数据
  3. 重建整个系统：包括硬件、操作系统、数据库软件和数据
  4. 实施数据保护措施：加密数据、实施访问控制、定期备份

故障诊断流程 ​

1. 故障检测 ​

故障检测是发现数据库故障的过程，包括主动监控和被动报告两种方式。

主动监控 ​

  • DB2健康监控：启用DB2健康监控，设置自动告警
  • 操作系统监控：监控CPU、内存、磁盘、网络等资源
  • 应用程序监控：监控应用程序响应时间和错误率
  • 日志监控：实时监控DB2诊断日志和操作系统日志

被动报告 ​

  • 用户投诉：用户报告应用程序无法访问数据库
  • 应用程序错误：应用程序返回数据库错误信息
  • 监控系统告警：监控系统发送告警通知

2. 故障定位 ​

故障定位是确定故障类型、影响范围和根本原因的过程。

步骤 ​

  1. 收集故障信息：

    bash
    db2diag -g component=DB2 -l ERROR
db2pd -db sample -all
db2 get snapshot for database on sample

  2. 分析故障现象：

    • 数据库是否可以连接
    • 应用程序是否可以执行查询
    • 数据库性能是否异常
    • 是否有错误日志生成

  3. 确定故障类型：

    • 根据故障现象判断故障类型
    • 使用诊断工具验证故障类型
    • 参考故障分类标准确定故障类型

  4. 定位故障根源：

    • 分析故障日志，寻找错误原因
    • 检查相关组件状态，确定故障点
    • 使用排除法逐步缩小故障范围

3. 故障恢复 ​

故障恢复是将数据库系统恢复到正常运行状态的过程。

恢复原则 ​

  • 数据完整性优先：确保恢复后的数据完整一致
  • 最小停机时间：尽量减少数据库停机时间
  • 恢复优先级：根据业务重要性确定恢复优先级
  • 验证恢复结果：恢复后验证数据完整性和系统功能

恢复步骤 ​

  1. 制定恢复计划：

    • 确定恢复策略和方法
    • 评估恢复时间和资源需求
    • 获得相关人员批准

  2. 执行恢复操作：

    • 根据恢复计划执行恢复操作
    • 监控恢复过程，记录恢复步骤
    • 遇到问题及时调整恢复策略

  3. 验证恢复结果：

    bash
    # 检查数据库状态

db2 connect to sample db2 list tablespaces db2 "SELECT COUNT(*) FROM schema.table"

检查应用程序功能 ​

运行应用程序测试用例 ​

检查性能指标 ​

监控数据库性能，确保恢复后性能正常 ​


4. **恢复业务访问**：
- 通知用户恢复完成
- 逐步恢复业务访问
- 监控系统运行状态

### 4. 故障分析与预防

故障分析与预防是总结故障经验，实施预防措施，防止类似故障再次发生的过程。

#### 故障分析

- **根本原因分析**：使用5W1H方法分析故障原因
- **故障影响评估**：评估故障对业务的影响
- **恢复过程评估**：评估恢复过程的效率和效果
- **经验教训总结**：总结故障处理的经验和教训

#### 预防措施

- **硬件冗余**：配置RAID、双电源、双网卡等
- **软件更新**：定期更新DB2补丁和操作系统补丁
- **配置优化**：优化DB2配置参数，提高系统可靠性
- **监控增强**：加强监控力度，及时发现潜在问题
- **培训教育**：加强DBA和用户培训，减少人为错误
- **备份策略**：制定完善的备份策略，定期测试备份恢复

## 故障恢复最佳实践

### 1. 建立完善的备份策略

- **定期备份**：根据业务需求确定备份频率
- **多种备份方式**：结合全量备份、增量备份、日志备份
- **异地备份**：将备份数据存储在异地，防止数据中心灾难
- **备份验证**：定期测试备份恢复，确保备份可用

### 2. 启用DB2健康监控

```sql
-- 启用健康监控
UPDATE DBM CFG USING HEALTH_MON OFF TO ON;

-- 设置健康监控参数
UPDATE DBM CFG USING HEALTH_CHECK_DB OFF TO ON;
UPDATE DBM CFG USING HEALTH_CHECK_IND OFF TO ON;

-- 配置健康监控告警
CALL SYSPROC.ADMIN_CMD('ALTER HEALTH CHECK DB2STALELOCKS SET ALERT STATE ON');

3. 建立故障响应团队 ​

  • 明确角色和职责：确定故障响应团队成员的角色和职责
  • 制定故障响应流程：明确故障响应的步骤和时间要求
  • 定期演练：定期进行故障响应演练，提高团队协作能力
  • 建立沟通机制：确保团队成员之间沟通顺畅

4. 使用自动化工具 ​

  • 自动化监控：使用自动化监控工具，如IBM Data Server Manager
  • 自动化告警：配置自动告警，及时通知DBA
  • 自动化恢复：对于常见故障，配置自动恢复脚本
  • 自动化报告：自动生成故障报告和性能报告

5. 持续改进 ​

  • 定期回顾：定期回顾故障处理过程，寻找改进空间
  • 更新文档：及时更新故障处理文档和恢复计划
  • 培训提高：持续提高DBA的技术水平和故障处理能力
  • 优化系统：根据故障分析结果，优化系统设计和配置

常见故障案例分析 ​

案例1：实例崩溃 ​

故障现象 ​

  • DB2实例进程意外终止
  • 所有数据库无法连接
  • 应用程序报错："SQL1032N No start database manager command was issued. SQLSTATE=57019"

故障原因 ​

  • 实例内存不足，导致实例崩溃
  • 错误的实例参数设置，导致实例无法分配足够内存

恢复过程 ​

  1. 重启实例：db2stop force; db2start
  2. 检查实例日志：db2diag -g instance=db2inst1 -l ERROR
  3. 调整实例内存参数：UPDATE DBM CFG USING INSTANCE_MEMORY AUTOMATIC
  4. 监控实例状态，确保实例稳定运行

预防措施 ​

  • 启用实例内存自动调整
  • 加强内存监控，设置内存使用告警
  • 定期检查实例日志，及时发现潜在问题

案例2：数据库日志满 ​

故障现象 ​

  • 数据库无法执行写操作
  • 应用程序报错："SQL0964C The transaction log for the database is full. SQLSTATE=57011"
  • 数据库性能下降

故障原因 ​

  • 事务日志空间不足
  • 存在长事务，占用大量日志空间
  • 日志归档失败，导致日志文件无法重用

恢复过程 ​

  1. 检查日志归档状态：db2 get db cfg for sample | grep -i archive
  2. 解决日志归档问题：db2 archive log for database sample
  3. 扩展日志空间：ALTER DATABASE sample ADD LOGFILE SIZE 1000
  4. 终止长事务：使用db2pd识别并终止长事务

预防措施 ​

  • 启用自动日志归档
  • 监控日志空间使用情况
  • 优化长事务，将其拆分为多个短事务
  • 配置合适的日志空间大小

案例3：表空间损坏 ​

故障现象 ​

  • 表空间状态变为"0x8000"（损坏）
  • 无法访问表空间中的表
  • 应用程序报错："SQL1562N The table space is in an invalid state. SQLSTATE=55039"

故障原因 ​

  • 表空间容器所在的磁盘损坏
  • 文件系统错误导致表空间容器不可用
  • 表空间容器被意外删除

恢复过程 ​

  1. 检查容器状态：db2pd -db sample -tablespaces -containers
  2. 修复或替换损坏的磁盘
  3. 恢复表空间：RESTORE DATABASE sample TABLESPACE (userspace1) FROM /db2/backup TAKEN AT 20240112143000
  4. 前滚表空间：ROLLFORWARD DATABASE sample TABLESPACE (userspace1) TO END OF LOGS AND COMPLETE

预防措施 ​

  • 配置RAID，提供磁盘冗余
  • 定期检查表空间状态
  • 实施定期备份策略
  • 监控磁盘健康状态

常见问题（FAQ） ​

Q1: 如何快速确定DB2故障的类型和影响范围？ ​

A1: 可以通过以下步骤快速确定故障类型和影响范围：

  1. 检查实例状态：使用db2start和db2 get instance命令检查实例是否正常运行
  2. 检查数据库状态：使用db2 list db directory和db2 connect to <dbname>命令检查数据库是否可连接
  3. 检查表空间状态：使用db2 list tablespaces for db <dbname>命令检查表空间状态
  4. 检查应用程序连接：使用db2 list applications for db <dbname>命令检查应用程序连接情况
  5. 查看诊断日志：使用db2diag命令查看DB2诊断日志，寻找错误信息
  6. 使用db2pd工具：使用db2pd命令获取数据库实时状态信息

Q2: 如何区分暂时性故障和永久性故障？ ​

A2: 可以通过以下特征区分暂时性故障和永久性故障：

  • 暂时性故障：通常可以自动恢复或通过简单操作恢复，如网络抖动、资源竞争、锁等待等，不会导致数据丢失
  • 永久性故障：需要人工干预才能恢复，可能导致数据丢失，如磁盘损坏、数据文件损坏、系统表损坏等

Q3: 如何预防人为错误导致的DB2故障？ ​

A3: 可以采取以下措施预防人为错误：

  1. 实施最小权限原则：只授予用户完成任务所需的最小权限
  2. 建立操作规范：制定详细的操作流程和审批制度
  3. 加强培训：定期对DBA和用户进行培训
  4. 启用审计功能：记录所有数据库操作，便于追踪和审计
  5. 使用自动化工具：减少手动操作，降低误操作风险
  6. 定期备份：确保有可靠的备份，以便在发生误操作时能够快速恢复

Q4: 如何制定有效的DB2故障恢复计划？ ​

A4: 制定有效的DB2故障恢复计划应包括以下内容：

  1. 故障分类和优先级：根据故障类型和影响范围确定恢复优先级
  2. 恢复流程：详细的故障恢复步骤和操作指南
  3. 恢复工具和资源：所需的工具、备份文件、硬件设备等
  4. 角色和职责：明确故障恢复团队成员的角色和职责
  5. 测试和演练：定期测试恢复计划，确保其有效性
  6. 更新和维护：根据业务变化和技术发展，及时更新恢复计划

Q5: 如何监控DB2故障？ ​

A5: 可以通过以下方式监控DB2故障：

  1. 启用DB2健康监控：设置自动告警，及时通知DBA
  2. 监控操作系统资源：监控CPU、内存、磁盘、网络等资源使用情况
  3. 监控数据库性能：使用db2top、db2pd等工具监控数据库性能
  4. 实时分析日志：使用日志分析工具实时监控DB2诊断日志和操作系统日志
  5. 使用监控软件：部署专业的数据库监控软件，如IBM Data Server Manager
  6. 设置告警阈值：根据业务需求设置合理的告警阈值

总结 ​

DB2故障分类是数据库故障管理的基础，通过合理的故障分类，DBA可以快速识别故障类型、影响范围和根本原因，选择合适的诊断工具和恢复策略，提高故障处理的效率和效果。

故障处理是一个系统工程，需要DBA具备扎实的技术知识、丰富的经验和良好的心理素质。建立完善的监控体系、制定合理的备份策略、实施有效的预防措施，可以大大减少数据库故障的发生，提高数据库系统的可靠性和可用性。

通过不断总结故障处理经验，优化系统设计和配置，DBA可以逐步提高数据库系统的稳定性，为业务应用提供可靠的数据库服务。