【问题描述】

上机操作日志查询表记录数非常多（100W以上），我们在排除大用户数、大业务量使用情况，通过查看上机操作日志表记录数，发现记录数已超过了1000万，存在明显的堆积没有归档的情况。如下图所示：

【场景介绍】

• 金蝶云星空上机操作日志与归档，默认归档规则是：如果上机操作日志记录数超过5w，每天凌晨2点左右，会把堆积的记录归档到上机操作日志归档表T_BAS_OPERATELOGBK。这样做可以确保上机操作日志表记录数不会堆积，表的记录数少，确保第二天的写入日志的性能；

【原因分析】

      存在异常的情况，导致了这种定期归档的作业没有正常执行，这个时候我们就需要对引发不能正常执行归档的问题做分析和处理；

      常见的原因有如下几个：

      第一，管理中心-数据中心列表，这个业务中心库的属性“允许执行后台作业”，没有勾选；

      第二，应用服务器，查看操作系统的服务发现，星空的服务K3CloudJobProcess服务没有正常运行；

      第三，执行计划列表中，日志归档服务被停止了，或执行的周期被修改成大于60分钟的值，导致未能正常执行；

      总之，如果上机操作日志表的记录数特别多，需要排查原因，进行正常的定期归档，减少上机操作日志表的数据量，以便在业务应用中，确保日志写入的性能。

【解决方案】

一. 主要步骤

1. 执行数据库查询脚本，初步判断日志清理和归档的情况；
   

2. 查看管理中心-数据中心列表，在业务中心库的属性“允许执行后台作业”，确认已勾选

3. 查看应用服务器，操作系统的服务，确认K3CloudJobProcess服务正常运行；

4. 查看计划列表，日志归档服务确保是准备状态，执行的周期如果大于60分钟，需要修改为60分钟；

5. 在上机操作日志表中，进行手工归档

二. 详细操作

1. 执行数据库查询脚本，初步判断日志清理和归档的情况：

有时候由于上机操作日志和归档表的数据量太大，想在产品端进行查询记录数，速度可能很慢，这是可在数据库中执行下面2个查询，获取相关表的记录数，用于判断归档和清理的情况，查询语句和说明如下：

--假设AIS20200630是业务数据中心，AIS20200630Log是日志库

--查询上机操作日志表的数据量，与日期最大最小值

select COUNT(*),MIN(FDATETIME),MAX(FDATETIME) from [AIS20200630].dbo.T_BAS_OPERATELOG

--查询上机操作归档表的数据量，与日期最大最小值

select COUNT(*),MIN(FDATETIME),MAX(FDATETIME) from [AIS20200630].dbo.T_BAS_OPERATELOGBK

--查看日志库中日志表的数据量，与日期最大最小值

select COUNT(*),MIN(FDATETIME),MAX(FDATETIME) from [AIS20200630Log].dbo.T_BAS_OPERATELOG

分析举例：

从上图数量来看，上机操作日志表的数据量不大，上机归档表中没有日志记录，日志库中有129187条操作日志。

说明，上机操作日志没有堆积情况，历史日志已归档到了日志库，现场配置了日志库，历史的日志在日志库中。

如果查询1的结果记录数很大，那说明有日志堆积在上机操作日志表；

如果查询2中有数据，查询3中没有数据，说明现场使用的是归档到T_BAS_OPERATELOGBK表；

如果查询2没有数据，查询3中有大量数据，那么说明现场采用了日志库，历史日志都在日志库中；

2. 查看管理中心-数据中心列表，在业务中心库的属性“允许执行后台作业”，确认已勾选

3. 查看应用服务器，操作系统的服务，确认K3CloudJobProcess服务正常运行；

4. 查看计划列表，日志归档服务确保是准备状态，执行的周期如果大于60分钟，需要修改为60分钟；

5. 在上机操作日志表的归档规则中，通过修改归档日期到第二天凌晨进行执行；

第二天，通过上机操作日志，或站点日志，可查看归档执行情况；

另外，如果站点（\Kingdee\K3Cloud\WebSite\App_Data\Log\20XX-XX-XX）的日志有记录INFO日志，也可以查看到归档和清理的日志信息；

【延伸阅读】

• 上机操作日志使用指南：https://vip.kingdee.com/article/8743?productLineId=1

• 《上机操作日志及其清理》课程链接：https://vip.kingdee.com/school/652?productLineId=1&isKnowledge=2