太钢SAP系统数据优化归档

项目实施建议

达美信息技术有限公司

2008.3
Agenda

项目概述

客户需求分析

解决方案介绍

项目实施安排

案例分析
项目背景

太原钢铁自2005年实施SAP ECC 5.0系统，并与2006年中上线。系统功能

范围覆盖FI, CO, MM, SD, QM, PP, PM, BW等领域。

随着业务发展，系统当中的数据也不断增多，目前数据库大小在1019GB左
右，并且还以每月大约50GB的速度增长，不断增多的数据对系统性能和业务正
常运作带来负面影响。目前典型的问题就是某些报表、程序和处理过程明显变
慢，严重地影响了业务的正常运行。且由于历史客观因素，部分主数据有冗余、
不完整等现象，为日常业务操作带来不便。同时，系统的正常运行所需的支持体
系完善化需求日趋紧迫，急需优化运维体系以降低系统面临的风险。

为了进一步提高太原钢铁的信息化应用水准，在现有投资下提高已有信息
系统产能，建议通过SAP信息生产周期管理方法来优化数据管理，从而减缓SAP
系统数据的增长速度，并结合必要的技术优化使SAP系统性能能有质的提高。工
作内容包括以下几方面内容：
数据清理
数据归档
性能优化
运维体系平台建立 (SolutionManager)
提升内部顾问相关技能(知识转移)
项目总体目标

长期保持太钢 SAP系统高效稳定运作，支持太钢业务高速发展。
提高SAP系统管理效率,满足业务和审计的需求。
降低在线数据占用空间。
减少数据库的数据负载。
对数据库进行重组，以优化SAP系统运行性能。
减少对总体资源成本的投入。
分析需要清理、归档的数据，并制定长期的归档策略，优化业务处
理模式，减缓数据库的数据的增长速度。
完善运营维护体系，满足未来系统稳定运作要求
建立以Solution Manager为平台的监控、管理和支持环境
提升内部人员相关技能
Agenda

项目概述

客户需求分析

解决方案介绍

项目实施安排

案例分析
客户需求分析

业务及审计角度：
太原钢铁系统上线时间较短 （<3年）
日常业务及数据处理与历史相关
在线数据应满足日常业务及审计需求
大量垃圾数据（主数据）为日常操作带来诸多不便

技术角度：
数据月增长量过大
大量占用存储空间，成本压力较高
物料帐相关的表容量大，性能问题严重

运维角度：
系统工作日志应定期自动清理
减少非必要性数据存放周期
规范系统维护及处理操作
数据库容量合理评估
平台及环境概述

SAP软件： ECC 5.0 + DIMP 5.0

数据库： Oracle 9.2.0.6

操作系统： HP-UX 11.23

DB

已分配容量： 1019GB

可用空间： 77GB

每月平均增长: 37GB
 数据库大小(G)
20
07

0
200
400
600
800
1000
1200
.0
4.
01
20
07
.0
5.
01
20
07
.0
6.
01
20
07
.0
7.
01
数据增长速度分析

20
07
.0
8.
01
20
07
.0
9.
01
20
07
.1
0.
01

日期
20
07
.1
1.
01
20
07
.1
数据库历史增长情况

2.
01
20
08
.0
1.
01
20
08
.0
2.
01
20
08
.0
3.
01
Series2
数据增长预测
 数据库分析：按照容量排序 - new
表名 描述 领域 容量 (GB)

SOFFCONT1 SOFF: 邮件内容表 (导入/导出) BC-SRVGBT 63.5

COEP 成本控制对象：与期间相关的各行项目 CO-OM 25.3
BSIS 会计核算: 总帐科目的次级索引 FI 24
BALDAT 应用程序日志: 日志数据 BC-SRV 18.5
FAGLFLEXA 总帐: 实际行项目 FI-GL 18
TST03 TemSe 数据 BC-SRV 17.8
CKIS 项目单位成本核算/产品成本核算分项列举 CO-PC 17
ACCTIT FI/CO 凭证的压缩数据 FI 16
MSEG 凭证段：物料 MM-IM 15.4
MLCR 物料分类帐凭证：货币和值 CO-PCACT 14
RFBLG 会计凭证集群 FI 13.8
MLIT 物料分类帐凭证: 项目 CO-PC 13.7
QAMV 检验处理的特性说明 QM-IM-RR 10.8
CDCLS 改变凭证集群结构 CA 10
ECMCA SAP 合并: 日记帐分录标 (实际) EC-CS 9.5
CKMLPRKEPH 物料分类帐: 价格的成本组件分割 FI 9
AUSP 特征值 CA-CL 8
MLPP 物料分类帐凭证：记帐期间和数量 CO-PCACT 7
BKPF 会计核算凭证标题 FI 6.8
COSS CO 对象:内部过帐成本总计 CO-OM 6.6
总计（20张表） 324.7
 数据优化方式分析：技术及可行性 - new
表名 描述 领域 数据清理 数据归档

SOFFCONT1 SOFF: 邮件内容表 (导入/导出) CA ★

COEP 成本控制对象：与期间相关的各行项目 CO ★ ☆
BSIS 会计核算: 总帐科目的次级索引 FI ★ ☆
BALDAT 应用程序日志: 日志数据 CA ★ ☆
FAGLFLEXA 总帐: 实际行项目 FI ☆
TemSe 数据 系统 ★
TST03

CKIS 项目单位成本核算/产品成本核算分项列举 FI ☆
ACCTIT FI/CO 凭证的压缩数据 FI ★ ☆
MSEG 凭证段：物料 MM ☆
MLCR 物料分类帐凭证：货币和值 ML ☆
RFBLG 会计凭证集群 FI ☆
MLIT 物料分类帐凭证: 项目 FI ☆
QAMV 检验处理的特性说明 QM ☆
CDCLS 改变凭证集群结构 CA ★
ECMCA SAP 合并: 日记帐分录标 (实际) CO ★ ☆
CKMLPRKEPH 物料分类帐: 价格的成本组件分割 FI ☆
AUSP 特征值 CA ★
MLPP 物料分类帐凭证：记帐期间和数量 ML ☆
BKPF 会计核算凭证标题 FI ☆
COSS CO 对象:内部过帐成本总计 CO ★ ☆
客户运维环境现状分析

系统监控方面：

系统管理员日常的监控工作方式是每天逐一登陆到每台服务器上进行系统日常维护
和系统监控的工作，根据不同的业务查看不同的数据源，工作量大，工作效率及其低下
，信息安全上也会有一定的问题。没有统一的平台来对整个的服务器架构进行概览以及
监控，对于日常系统管理员的工作量无法衡量。

运维支持体系方面：

目前太原钢铁自身的支持体系为当最终用户遇到问题的时候，先通知信息化项目部
的支持人员请求解决，当支持人员解决不了问题的时候，会找到咨询公司或者通过OSS来
请求SAP帮助解决问题。这种支持流程，目前借助于邮件、电话等手段来完成。

在目前方式下，为提高太钢SAP系统运营维护管理水平，可以在以下几方面完善支持
体系：
对SAP ECC、BW、EP等环境建立集中式实时监控体系，及时了解目前系统状况
对SAP各相关组件采用集中管理模式，优化管理流程
建立内部支持体系和知识库，并通过知识转移提高内部顾问能力
针对太原钢铁目前现状的建议

数据清理为主 建立集中监控体系
业务数据 实时监控个生产环境运行状态
主数据 集中管理

部分数据以归档为手段 优化内部管理，强化运维体系
业务数据 明确管理规范
主数据 固化操作过程

优化及规范数据管理 知识转移
数据库 客户化培训（与客户环境相结合）
系统作业 工作过程培训（与实践相结合）

依据业务状况优化系统整体性能 针对未来发展长远规划
标准功能、客户化开发优化 业务流程优化
系统配置优化 系统体系架构规划
Agenda

项目概述

客户需求分析

解决方案介绍

项目实施安排

案例分析
 系统整体性能优化的方式

以数据为出发，结合系统环境特性，面向应用和业务流程，长期持续的原则

以数据为核心 面向应用和业务流程
数据清理 以业务领域展开
数据归档 和周边集成系统相结合

结合客户自行开发程序
针对客户实际环境 程序优化
存储子系统 – 分区方式 知识转移
操作系统 I/O 参数
数据库内存管理, 索引 建立长期稳定的运维体系
规范化操作流程
SAP内存、进程、缓存
健壮稳定的支撑平台
SolutionManager
性能优化 - 信息生命周期
数据处理的几种方式
SAP数据归档 - 系统架构
SAP数据归档 – 内部结构

把数据记录从数据库中移出，存放在归档文件中。数据归档是通
过归档对象（Archiving object）实现的。
SAP数据归档 – 处理过程

创建归档文件：
归档程序从数据库中
读取数据，把需要归
档的数据写入归档文
件中

删除数据：
首先，删除程序读取
归档文件，确认归档
数据已写入归档文
件；其次删除程序从
数据库中删除已确认
归档的数据。

转存数据：
将归档完成后生产的
所有归档文件转移到
其他的存储空间。
 SAP数据归档 – 查询归档数据

SAP提供了多种方式查询已归档的数据
直接读取单个凭证（仅针对FI_document和MM_MATBEL两个对象）
通过report查询，针对SD和PP模块的归档对象，SAP提供了特定的
report模板，用户可以复制并修改report模板，生成自己的报表程序
（report program）读取需要的归档数据。
通过SARA（T-CODE） 提供的分析工具，可以选择归档文件，查询
所需的归档数据。
信息系统: SAP AS（Archive information System），用户根据需
要，可以创建自己的信息系统，用于查询已归档的数据。

可以依据太钢集团的需求，开发或利用第三方工具软件
实现特有方式查询已归档的数据
 SAP数据归档 – 底层工具ADK

SAP提供的标准Archiving工具是Archiving Development Kit (ADK).

ADK
 BW数据归档模式: BW and ADK 集成

InfoCubes

归档文件

ODS
object

归档文件

SAP Functionality - ADK 3rd party products

 BW归档过程

归档对象
- Manually or automatically
- Selects Data according to started
selection criteria - Deletes data according to
- Locks DataTarget selection criteria
- Write to file(s)
- Verifies data written
DataManager
Archive
InfoCube 读 Administration
写 (SARA)
Scheduled
删除
删除

校验
ODS object 读取 Datamart
Extractor

ADK - Reads archive data

using archives
objects defined
File system, CMS, HSM file structure
考虑使用第三方软件管理归档文件

在完成数据库的归档后，可以考虑是否使用第三方软件来实现对
归档数据的管理。第三方软件有助于更系统地管理归档文件，增强对
归档文件的访问控制。可以选择的第三方软件包括IBM
CommonStore，EMC Documentum 和OpenText IXOS等。

主要工作包括：
安装第三方软件
SAP/R3 与第三方软件接口配置
SAP archive link 设置等
数据归档和优化的目的与时机

目的： 时机：

SAP建议数据归档计划从SAP系统
降低在线数据占用空间
上线时就开始考虑
优化R/3系统运行性能
制定长期归档策略，建立SAP数
提高SAP系统管理效率 据归档制度

满足业务和审计的需求 建立归档操作流程和方法

降低总体拥有成本
性能优化方式

SQL 语句优化 客户程序优化 应用优化 Basis优化

定位和优化大量 定位和优化关键 分析和优化核心 分析和优化SAP

消耗资源的SQL 客户自行开发程 业务流程的资源 系统安装及配置
执行过程 序 消耗和运作时间 相关问题
标准应用优化

分析和优化核心业务流程的资源消耗和运作时间

核心业务流程 - 将资源消耗型关键任务和时间消耗型任务合理分布
至系统各节点（将任务拆分为多环节多步骤子任务方式）

对各步骤或环节分析，并定位资源瓶颈，分析优化可行性
客户化程序性能优化

定位和优化关键客户自行开发程序
分析自行开发的插件、以及对SAP标准程序的更改

消除客户自行开发（含项目开发）程序中的性能瓶颈

优化方法：
优化ABAP和SQL代码
分析关键程序和事务代码
分析程序当中的Open SQL访问过程
分析数据量较大的internal tables的处理过程
优化应用设计
调整实施配置和业务流程设计
减少资源占用
优化时间消耗型关键步骤
改善业务完整性设计和优化锁时间
监测逻辑工作单元 (LUW)
采用SAP Enqueue 机制保护 LUW
优化数据库锁时间
SQL 语句优化

定位和优化大量消耗资源的SQL执行过程，以提高核心关键业务处理
过程的吞吐量

优化方式：
更新数据访问优化器统计信息
调整和更改ABAP程序

优化用户输入

创建、拓展或更改索引
ABAP报表调优
SAP R/3 Basis 优化

分析和优化SAP系统安装及配置相关问题

优化方式：

优化硬件配置 – 存储分区，I/O通道等

优化软件配置 – OS, DB …

针对CPU及内存检查和优化SAP系统潜在瓶颈

优化表缓存

优化负载分布方式

系统运行参数调整
数据库重组

离线方式：
需停机进行

整体运行时间短

实施难度低

在线方式：
可在线进行

整体运行时间长

运行期间对整体性能有负面影响

实施难度高
9i支持，10g功能有所优化，可采用第三方工具NORAD DB Control, Quest's
LiveReorg
 系统支持运维平台：Solution Manager
协同 客户
支持运维体系的运作平台和工作环境
SAP
Efficiency Transparency
产品研发
SAP Solution Manager 高效性 透明度
知识，流程
透明化
客户化开发

实施

运维
实施SAP相关产品和解决方案
SAP 核心业务
产品支持服务 流程
解决方案运行监控

用户支持体系
优化
咨询服务商 变更管理系统
Control
SAP支持服务渠道 控制 Flexibility
灵活性
培训和知识转移 问题诊断工具

升级过程指导

托管服务
标准化集成管理平台
集中监控和管理体系

BW
BW EP
EP

QAS
QAS TST
TST

DEV
DEV ECC
ECC

系统管理员 系统监控

集中监控系统

SAP解决方案管理器

SAP Support 外部支持

 支持体系总体设计

寻求解决
企业最终用户/ 太钢支持中心 问题转发 咨询公司 方案 SAP 服务门户
项目实施小组

1 2 3
解决方案 获得参考
SAP 系统 提供解决方案 管理器 提供解决方案 方案
SAP
解决方案管理器
或 SAP Note 数据库
最佳业务实践数据库
SAP服务产品
提供解决方案 转发问题

4
SAP支持

5 客户方知识库

提供专业解决
提供最终解决方案 方案

内部 外部
Agenda

项目概述

客户需求分析

解决方案介绍

项目实施安排

案例分析
 项目实施总体计划

项目准备 蓝图设计 功能实现 上线准备 上线及支持

运维体系
规范优化 IT管理 IT管理 培训及
现状分析 规范设计 知识转移

系统性能 应用及自发开
程序SQL优化 Basis系统优化
优化 程序分析

监控支持
平台建设 SLM安装
EWA实现 支持体系建立 上线运行

数据清理
组建项 数据及 制定归档 归档实施
和归档 目团队 业务分析 策略和计划
归档测试
及后续工作

现在 2008.5 2008.6 2008.7 2008.8 时间

 项目实施 – 数据清理和归档

组建项 蓝图规划 制定归档策 归档实施及

归档测试
目团队 数据分析 略和计划 后续工作

•项目经理 •表大小分析 •数据对象在系统 •SAP相关notes •测试评估

中保留的时间
•技术人员 •表增长率 •创建变式 •确认归档配置传
•未来审计方式及 输
•最终用户（审 •归档对象分析 相关文档支持 •系统集成测试
计人员） •生产系统数据归
•归档对象业务 •建立归档时间进 •归档配置传输 档
•业务流程负责 依存关系 度表及活动定义
人 •数据库重组及后
•业务流程分 •系统长期归档策 续相关工作
•外部相关软硬 析、工作范围确 略的制订
件厂商 定
•服务器配置
•权限分析 分析阶段 数据归档
•归档客户化开发 阶段
•存储设备 数据整理 系统数据
实施和上线 归档/清理
报告

技术分析 数据库对象
分析报告 模拟归档

内部测试

业务分析 上线运行

总体空间
归档/清理 后续工作 评测报告
数据分析 业务分析
报告

归档/清理
计划和策略 计划和策
略报告
项目实施 – 监控支持平台建设

SLM安装 支持体
上线运行
EWA实现 系建立

• SLM系统的安装 •服务级别报告的生成 •上线支持和调试

•卫星系统信息收集 •测试系统：支持体系模 •持续改进
拟运作
•监控范围和指标的确认
•生产系统：支持体系正
•卫星系统的配置检查 式运作
•SLM系统与卫星系统的 •SLM用户权限设置和测试
连接
•SLM 项目文档编写
•SLM系统监控指标配置
•知识转移
•系统监控：连接到生产
服务器
•系统集中管理和监控
项目实施 – 系统整体性能优化

应用及自开 Basis优化
程序SQL优化
发程序分析

•分析关键程序和事务代 •更新数据访问优化器统 •优化硬件配置 – 存储

码 计信息 分区，I/O通道等
•分析程序当中的Open •优化用户输入 •优化软件配置 – OS,
SQL访问过程 DB …
•创建、拓展或更改索引
•分析数据量较大的 •针对CPU及内存检查和
internal tables的处理 •ABAP报表调优 优化SAP系统潜在瓶颈
过程
•优化表缓存
•监测逻辑工作单元
(LUW) •优化负载分布方式

•分析数据库锁时间 •系统运行参数调整
项目实施 – 运维体系规范优化

IT管理 IT管理 培训和

现状分析 规范设计 知识转移

•现状调研 •系统管理规范 •系统管理培训

•IT支持流程设计 •变更管理规范 •管理流程培训
•管理体系建议 •问题处理规范 •监控平台培训
•开发规范 •数据归档培训
 阶段一：项目准备阶段

时间周期： ‾ 1周
工作内容：
组建项目团队 SLM安装及环境准备
• 项目经理 • 系统安装
• 技术人员 • 系统连接配置
• 最终用户（审计人员） • EWA数据收集激活
• 业务流程负责人
• 外部相关软硬件厂商

制定工作计划
• 项目目标确定
• 工作计划和进度确定
 阶段二：蓝图分析阶段

时间周期： ‾3周
工作内容：
归档技术分析 IT管理现状调研
• 现状调研
• 收集数据库表的大小和增长率等信
• IT支持流程设计
息。
• 管理体系建议
• 性能影响分析
归档业务分析 应用及自开发程序分析
• 分析关键程序和事务代码
• 表->归档对象
• 分析程序当中的Open SQL访问过程
• 归档对象业务依存关系
• 分析数据量较大的internal tables
• 业务影响分析
的处理过程
归档数据分析
• 监测逻辑工作单元 (LUW)
• 业务流程分析，工作范围确定
• 分析数据库锁时间
• 归档数据查询权限分析
 阶段三：功能实现阶段

时间周期： ‾5周
工作内容：
创建归档策略： 确立IT规范：
• 确定数据清理范围 • 系统管理规范
• 确定归档对象 • 变更管理规范
• 未来审计方式及相关文档支持 • 问题处理规范
建立归档计划： • 开发规范

• 建立数据归档计划 关键程序和SQL优化：
• 数据归档进度及工作内容确定 • 更新数据访问优化器统计信息
设立长期的归档制度: • 优化用户输入

• 制定长期数据归档制度。 • 创建、拓展或更改索引

系统配置： • ABAP报表调优

• 归档策略配置
开发（可选）：
• 利用ADK开发客户化归档功能。
 阶段四：上线前准备阶段

时间周期： ‾4周
工作内容：
系统集成测试： 支持平台建立：
• 服务级别报告的生成
• 业务流程变更确认
• 测试系统：支持体系模拟运作
• 数据归档过程确认
• 生产系统：支持体系正式运作
系统配置传输：
• SLM用户权限设置和测试
• 配置确认及传输
• SLM 项目文档编写
配置变式创建：
Basis系统优化：
• 归档策略确认，定制变式
• 优化硬件配置 – 存储分区，I/O等
培训和知识转移：
• 优化软件配置 – OS, DB …
• 系统管理培训
• 优化CPU及内存管理
• 管理流程培训
• 优化表缓存
• 监控平台培训
• 优化负载分布方式
• 数据归档培训
• 系统运行参数调整
 阶段五：上线及支持阶段

时间周期： ‾4周
工作内容：
集成测试评估： Basis系统持续优化：
• 系统运行参数调整
• 测试效果评估和确认

系统数据清理： 系统月结支持：
• 关键业务过程支持
• 数据清理运行
• 系统性能数据更新
系统数据归档：
系统归档数据访问支持
• 小批量数据归档
• 大批量数据归档作业制定

数据库Reorg：
• 在线数据重组
• 离线数据重组
阶段五：上线及支持阶段

测试评估
传输：
配置信息同步至生产环境
生产系统数据归档
数据库整理和后续动作

归档过程中系统部分表被移出，这样系统数据库会出现一定程度的
数据库碎片。因此需要对归档后的数据库系统进行一次数据库的整理
动作，以提高数据库系统的性能。
项目组织架构

项目指导委员会

太钢项目经理 1 人
达美项目经理 1 人

数据优化归档小组 SLM和性能优化小组 运维体系规范咨询小

组
达美： 达美：
归档顾问1人 技术顾问 1人 达美：
技术顾问1人 SLM咨询顾问 1人 咨询顾问 1 人
应用模块顾问6人
太钢： 太钢：
太钢： 运维主管1人 运维主管1人
Basis顾问1人 运维工程师1人 运维工程师1人
对应模块顾问6人
对应关键用户6人
项目风险与成功要素

系统平台的性能量化评估

需要归档的数据量-在满足业务正常运作的前提下

数据清理和归档的顺序，避免逻辑数据残留

归档时系统的负载，协调安排非业务高峰时段

数据库重组，离线与在线相结合

业务、技术团队的密切合作，来自领导的有利支持

管理流程的规范化，运维体系的完善
须长期关注的内容

系统必须满足财务上审计的要求以及业务上的追溯对比需求。
所有业务数据在系统中的驻留时间建议为一个完整的会计年度。

定期归档,每年从1月份开始，归档前年的所有业务数据。

定期删除,每月1日删除前一个月的历史日志数据。
业务数据的归档对象顺序 :

持续的优化过程

不断提高支持人员业务技能

业务流程的完善和改造

............
.....
...
Agenda

项目概述

客户需求分析

解决方案介绍

项目实施安排

案例分析
 案例分析：民生银行

民生银行R/3系统数据库增长统计

600

500

400

数据库容量 300 每月增长量

数据量容量
200

100

0
2005年3月 2005年5月 2005年7月 2005年9月 2005年11月 2006年1月
日期

生产系统数据库目前大小为636GB，其中已使用空间为479GB，以平均25GB/月
的速度增长 .
前20位表共占用空间352GB，占总数据库空间的73% .
 数据归档策略

归档对象及策略:
归档对象 归档对象描述 对应表 归档策略

COPA1_CMBC 获利能力分析（基于成本核算） CE1CMBC\CE3CMBC 归档2003/2004年的数据

成本控制中利润中心会计的实际 归档2003/2004/2005年的
EC_PCA_ITM GLPCA
行项目信息 数据

COEP\COBK\COSS\C
CO_ITEM CO行项目 归档2003/2004年的数据
OSP

CO_COSTCTR CO内部订单 COEP\COBK\COSP 归档2003/2004年的数据

定期删除:
数据产生来源 对应表 归档策略

EDT外部数据导入产生的日志 DDPRH/DDPRS/INDX 每月定期删除

用户自定义表，每月更新一次 ZCE1CMBC 每月定期删除

归档效果（1）生产系统

完成生产系统数据归档及后续工作后：

1. 数据库大小大幅下降：与归档之前相比，本次归档完成后数据库已
使用空间由480GB降至278GB，总共释放出约202GB的可用空间。
2. 系统备份时间显著缩短：归档前，生产系统一次完整的离线备份耗
时12小时50分钟；归档完成后，一次完整离线备份的时间是：6小
时左右。相应的，如果出现系统故障，系统恢复所需要的时间也大
大缩短。
3. 数据库表空间及表的数据碎片大大减少，性能提高：通过归档后对
PRD＃BTABD和PRD＃CE1CMBCD两个表空间的重组，清除了数据
碎片，数据库获得了连续的可用空间，性能有所提高。
4. 由于数据减少，SAP R/3系统业务操作的响应时间也略有提高。
 归档效果（2）开发系统

1. 数据库大小下降：归档完成后数据库已使用空间由400GB降至
230GB，总共释放出约170GB的可用空间。
2. 系统备份时间缩短：归档前离线备份耗时11小时22分钟；归档完成
后离线备份的时间是：5小时49分钟。系统恢复所需要的时间也相
应缩短。
3. 数据库表空间及表的数据碎片减少，性能提高：通过归档后对DEV
＃BTABD表空间的重组，清除了数据碎片，获得了连续的可用空
间，性能有所提高。
4. 由于数据减少，SAP R/3系统业务操作的响应时间也略有提高。
 数据归档后的数据读取

数据归档后如果需查询归档数据, 使用以下步骤:

1.首先到BW系统中进行查询.
2.如果需要查询详细信息则到事务码SARA(数据归档相关操作)、SARI（信息系
统）中查询.

注：由于目前民生银行SAP系统只使用了COPA这个模块，归档文件数量不多，
因此未使用第三方软件(如IBM CommonStore)对归档文件进行管理和数据读
取。如以后使用多个应用模块，并进行了归档，建议考虑使用第三方软件管理
归档文件。
 数据归档后的数据安全

为了保证归档后的数据是有效的、安全的，建议使用以下方法：

1、首先保存归档文件到磁带上（双份）。

2、由于磁带为易耗品，在保存到磁带上的同时，最好将归档文件存放于光盘或

其它硬件设备上，保证数据归档后的数据安全。

如归档文件数量较大后，建议考虑采用第三方软件统一对归档到磁带的归档文

件进行管理，便于用户查询、读取归档数据文件，提高数据安全性。
 数据归档长期策略

由于系统必须满足财务上审计的要求以及业务上的追溯对比需求，所有业务

数据在系统中的驻留时间建议为一个完整的会计年度。

定期归档：每年从1月份开始，归档前年的所有业务数据；

定期删除：每月1日删除前一个月的历史日志数据；

业务数据的归档顺序为：

COPA1_CMBC EC_PCA_ITM CO_COSTCTR CO_ITEM.

案例分析：中石化数据归档试点单位-湖南石油

数据库目前总体已使用空间为210GB，以平均8GB/月的速度增长 .
前20 位表共占用空间 110GB左右，占总数据库空间的52% .
 重点归档对象

重点归档对象:
归档对象 归档对象描述 对应表 建议归档策略
归档 2005年前(包括05年)的
MM_ACCTIT ACCTIT
数据

MM_MATBEL 物料凭证 MSEG\MKPF\MSEG01\MSEG02 归档2004年前(含2004)的数据

COPA1_SINO 获利能力分析（基于成本核算） CE1SINO 归档记录类型为A的所有数据

COPA2_SINO 获利能力分析（基于财务） COEP\COBK\COEPL 暂不归档

成本控制中利润中心会计的实际行项目 归档 2005年前(包括05年)的
EC_PCA_ITM GLPCA
信息 数据

CO_ITEM CO行项目 COEP\COBK\COSS\COSP 需与用户讨论，未确定

CO_COSTCTR CO内部订单 COEP\COBK\COSP 暂不归档

SD_VBAK 销售订单 VBAP\VBAK 归档2004年前(含2004)的数据

归档2004年前(含2004)的数据
RV_LIKP 销售交货凭证 LIPS\LIKP

FI_DOCUMNET 财务凭证 BSIS\BKPF 需与用户讨论，未确定

 湖南石油SAP系统归档大表

表名称 表空间 表容量(KB) 总条数 或可归档条目数(空间GB)

GLPCA PRD#BTABD 27950214 21514004(11.6GB)

15，008，800

ACCTIT PRD#BTABD 11，797，520 16114500 12192480(9GB)

MSEG PRD#BTABD 10，092，560 8776697 3075159(3.5GB)

CE1SINO PRD#BTABD 10，027，040 17387482 8445592(4.9GB)

LIPS PRD#BTABD 480，5833 1922333(2.6GB)

6，488，064
BSIS PRD#BTABD 23187057 未定
7，799，808
Z04A PRD#BTABD 7，340，032 ALL ALL(7.3GB)

TOTAL 69GB 39GB

湖南石油其他需要归档表

除上述已列出需要归档的大表外，还有下列相关较大的表需要归档：
MSEG01/MSEG02

MKPK/NAST

VBAK/VBAP

VBRK/VBRL

LIKP

LIPS01/LIPS02

BKPF

ACCTCR

以上诸表总共大小约为：22GB，可归档数据约为10GB左右。
湖南石油SAP系统归档预期效果

综合前面分析：

湖南石油SAP系统归档涉及表总大小约为91GB

可以归档出的数据总大小约为49GB

可归档出的数据占目前数据库总体使用空间的约23％

长期归档效果：

通过归档项目的实施，可以建立一套在今后较长时间内行之有效
的归档策略。湖南石油用户根据归档策略能够定期对数据进行归档，保
持数据库大小基本保持在一个稳定水平。
海信集团

(2004年中旬上线,归档04~05年数据)

项目实施效果：通过实施归档，实现了最初的设想，即在保证数据
安全前提下，管理包括业务文档在内的各种类型的归档数据， 从而实
现系统高效运行的目标。而且最大限度的节约了成本。

归档后，数据库大小由862GB下降至601GB左右。 将硬盘和数据
库的压力通过归档软件转移到磁带库进行管理，一方面缓解了对硬盘的
需求，减少了硬盘的采购成本，同时也将数据库的压力转移到磁带库。
 达美Solution Manager实施成功案例介绍

2006年5月，达美为中石化成功实施了Solution Manager系统监控模块，
其中包含的内容有EWA和SLR报告的生成以及多台SAP系统监控，中央
系统管理。

2006年6月，达美为中国石油成功实施了Solution Manager实施模块，
其中包含的内容有项目的建立，业务蓝图，系统配置以及测试等。
 达美Solution Manager实施成功案例介绍

2006年7月，达美为上海通用汽车成功实施了Solution Manager系统
监控模块，其中包含的内容有EWA和SLR报告的生成以及多台SAP系统
监控，中央系统管理。

2006年12月，达美为海尔成功实施了Solution Manager项目一期，主要
为系统监控模块以及SMD模块，其中系统监控模块包含的内容有EWA和
SLR报告的生成以及多台SAP系统监控，中央系统管理。SMD模块包含的
内容有对XI和Portal中的JAVA部分进行监控。
2007年7月，达美为海尔正在实施Solution Manager项目二期，主要内容
为Service desk，BPM以及Change Management三个模块。
 达美Solution Manager实施成功案例介绍

2007年3月，达美为欧琳厨具成功实施了Solution Manager的Service desk

模块的内容。

2007年4－7月，达美通过Service desk的成功实施，成功为自己申请SAP
CCC认证。

2008年1月，中远SLM项目正式启动，目前正在实施中。
Appendix

附录：关键数据对象处理方式
COEP - 1

系统自动为每个流程创建一条CO行项目，在该流程中，一个对象从属于所用的控制（例如，一个销售订单或者成本中心）。该行项目的创建用于对结算凭证
或者财务会计的补充。

参见SAP Notes:

178921 (release-independent) gives an overview of what you can do if table COEP experiences a rapid increase in the volume of data it contains.

138688 (SAP R/3 Release 3.0D - 4.6C) can be used to upload analysis programs RARCCOA1 and RARCCOA2 in your system.

这两个程序允许进行以下操作：

- 这些程序可以告诉你在一个对象类型中，例如一个控制范围和一个会计年度中存在多少数据。

- 可以定义应该使用哪些归档对象移除CO数据。CO表中的条目（COEP, COSP, COEJ...）被计算并且明确的分配到了一个归档对象。

即使利用程序RARCCOA1 或者 RARCCOA2执行的分析结果也包含了归档对象CO_COSTCTR，仍不应使用该归档对象去归档属于成本中心的行项目，可以
使用归档对象CO_ITEM作为代替。CO_COSTCTR不是一种减少表COEP （对于表COEJ也一样）的很好选择。
影响性能的关键流程

更新可以被不同的流程激活，例如收货和收发票。根据客户个性化设置，至少为原始凭证中的每个凭证项目在表COEP中产生一个条目。
预防

可以禁止激活表COEP 或者 COSP的统驭对象行项目和总记录的更新。参见SAP Note 182496。

当为一个新的期间执行变式或者WIP计算时，每个生产订单的CO中将更新大量新的数据记录。你可以通过移除许多配置指示器来避免此种情况发生，如SAP
Note 393686所述。这样也将改善归档生产订单 PP_ORDER对象的性能。通过一个特殊的删除程序，那些已经被写入的记录可以被删除。参见SAP Note
310089。
整合

可以激活行项目的整合(见SAP Note 147766, SAP R/3 Release 3.1I - 4.0B) 。整合在数据上并没有立竿见影的效果,因为它仅指向未来的过账.旧文件没有受

到影响,所以归档可能仍然需要.

可以使用行项目整合,以确保该系统不会为CO的每个行项目产生原始凭证(例如,一个原材料过账) 。行项目整合确保选定的字段不再出现在行项目报表中。由
于这些字段不直接影响成本会计因此不会出现其他的影响。

如果使用了转让价格，则不能使用行项目整合。

SAP Note 195480 (SAP R/3 Release 3.1I - 4.70) 包含了一个可以模拟凭证整合的程序，从而使你确定是否存在价值对凭证进行整合。

COEP - 2

在层次定义上使用不适当的特性,可以不必要的增加表COSP 和 COSS的大小。尤其是对于整合对象的关键字段，如"订单号码" ,可以影响表的大小。这就是

为什么每次整合前,你应该检查哪些因素才是在层级中实际需要的原因。只有确实需要的字段才是整合的一部分。在某些情况下,您还可以从层次关系中删除整
个层次。
删除

不能使用。
归档

可以使用分析程序见SAP Note 138688 ,以确定哪些归档对象可用于归档表COEP中的条目。过程如下:

1 )只用涵盖最大数据量的归档对象。正常情况下, 2-3归档对象将覆盖90 %的有关数据.

2 )已使用(定期)一个相关的对象。如果是这样的话,你应该按如下进行:

a)利用此对象归档后重复进行表分析。为了做到这一点,再次运行程序RARCCOA1。这应当意味着此对象将存在相当少的数据出现在程序RARCCOA2的清单
中。

b)然而,如果RARCCOA2清单中出现了同样数量的数据，你应该通过使用被讨论的对象来加强归档。改变一些数据,例如减少滞留时间或扩大你的选择标准。
但在这样做之前,必须联络有关部门。

c )如果先前的方法一点也没有使情况好转，并且你不再需要相关对象类型的CO行项目，那么你应该将相关归档对象类型标记为CO_ITEM。

3 )如果需要,你可以为其中一个对象定义计划归档。考虑到定位于表COEP的数据，你应该给这个归档作业更高的优先作业权。使用CO_ITEM 可能会更费时
。

4 )如果出现了归档对象CO_COSTCTR,你也应该考虑存档对象CO_ALLO_ST.过程如下:

a )定义程序RARCCOAA作为后台作业在某个过账负担小的时段运行。

b) RARCCOAA在表COEP 和 COEJ中生成一个条目清单。该清单指向那些已经被取消的凭证。如果系统返回一个相当数量的条目,你应该使用归档对象
CO_ALLO_ST。

CO_ALLO_ST还可以用来处理最新数据.归档凭证都是已被取消的成本会计凭证。任何情况下它们都不影响你的数据。这些文件在以下情况时创建,例如当数
据被重新分配或重新评估时。

5 )如果在程序RARCCOA2的列表中仍然存在相当大量的条目或者如果你已经选择了为执行CO_ITEM归档的对象类型，那么你可以考虑去完善该归档对象。

可以使用CO_ITEM为能被归档的对象类型创建一个清单。在产生对象类型清单时，排除已经被不同归档对象覆盖的所有因素。
COEP - 3

表分析

如果在数据归档之前想运行表分析（事务TAANA），对相关表提供了以下分析变量：

Table

Analysis Variant

COEP

BUSINESS_TRANSACTION

COBK

REFERENCE

参见SAP Notes：

200480 (release-independent): Provides help if, when using CO_ITEM, too little or nothing was archived because, for example, the wrong object
type or the wrong logical system was set in Customizing.

200513 (release-independent): Explains when entries are deleted from table COBK. In contrast to Financial Accounting, line items in CO are
archived by object rather than document. It can therefore occur that many document line items (such as COEP and COEJ) were deleted, but not
a single record from table COBK.

注意在使用对象CO_ITEM归档数据时的性能:

在写程序时为了达到最高性能:

1 .只为一个单一的对象类型开始写程序。在选择屏幕输入对象类型。

2 .只为一个单一的对象类型开始写程序。

3 .在一次归档操作中尽量对多个期间归档。我们建议您不指定任何数据给"期间至"或"会计年度至" 。这就是说,只使用滞留时间。我们建议您不要对不同的"
期间至"或"会计年度至"运行超过1个归档操作。限制期间和年度并没有显着提高运行性能。

如果你只想归档计划行项目（表COEJ），那么输入一个期间的做法就没有意义。计划行项目始终保持在一年水平并只用于归档完全被选择的会计年度。例
如,如果你在period to里输入2002，并且在posting period过账期间里输入6,那么系统只会归档计划行项目到会计年度2001，因为2002年不完全落入了选择
。

4 .不要与CO_ITEM同时运行归档界面。此外,不要在运行RARCCOA2清单中出现其他归档对象的同时开始归档运行CO_ITEM。
TST03

表TST03是组件TemSe（临时顺序输出文件）的数据库表。该表用于存储从打印和输出控制器中存储的打印数据，例如打印请求和后台作业日志（在其他数
据之间）。

该表也包含了数据例如不同的测试数据，中间的HR数据，审计信息系统的数据输出等等。我们不具备考虑到其他的数据类型的数据管理信息。因此，该章节
仅仅聚焦于打印数据。

事务SP12（Management of TemSE Data)是分析表TST03的一个辅助工具。例如使用TemSe Data Storage → Memory Allocation可以显示对于TemSe

Objects的记忆分配。

尽管对于SAP R/3 4.0而言打印数据库具有接受20亿打印请求的能力，仍然建议最好使用以下的预防和删除操作，以避免瓶颈和性能问题。

预防
下述3种操作帮助你避免表TST03中的不必要的条目：

　 输出后自动删除打印：在打印控制中你可以对于所有的用户设置输出后删除作为默认设置。如果个人用户不明确选择保存他们的打印，这将导
致所有用户的所有打印将在输出后自动被删除。

　 在文件系统中保存打印数据：可以设置打印机将数据不存储在表TST03中，而是存储在文件系统的文件中。为达到此目的，设置参数值
“rspo/store location” 从“db” 变为“G” (参见 SAP Note 10551, release-independent)。该操作在对打印数据的写和读操作过程中改进了性能，因为系统比
数据库执行速度更快。该操作的缺点是数据不能在定期的数据库恢复中同时被恢复。

　 关于工作台的更好使用：如果你改变参数LONG_RAW到一个更加合适的长度（参见SAP Note 140547,与版本无关)，当数据记录被保存的时

候将会有更少的浪费。SAP也建议在使用此方法的同时，减少参数PCTFREE从10到1（参见SAP Note 140547,与版本无关）。这意味着当从空闲清单中获取
空间的时候在数据块中需要更少的空间去保持空闲。然而，这只与新写入的记录有关。该建议适用于所有的数据库，但是Oracle数据库的保存潜力最大。（
参见Note 572060)。

　 防止打印请求的创建：你可以分配一个输出设备名称为NULL，意味着对于此类用户而言不会创建打印请求。然而，这只对ABAP打印清单有
效，而对于SAP手稿文本则无效。如果你不想打印SAP手稿文本，或者想保留打印数据，那么就不要立即选择创建打印请求并且日常状态下使用程序
RSPO1041 (见下述)。更多信息参见SAP Note 181571。
删除
可以使用程序RSPO0041 和 RSPO1041删除过去的打印请求，这些程序在后台执行。RSPO1041是R/3 4.6A中标准的一部分并且是程序RSPO0041 (参见
SAP Note 130978, SAP R/3 4.6A – 4.6B, 4.6C – 4.6D, SAP Web AS 6.10-6.40)最新的版本。两个程序都有同样的目的，但是RSPO0041考虑到限制选择打
印请求被删除而具有许多缺陷，这些缺点在新程序中不再出现。关于程序RSPO0041的信息参见SAP Note 41547 (与版本无关)。

如果你使用这些程序，在任何情况下都不要同时在打印管理中激活按钮自动删除过去的打印请求。（找到这个函数，通过路径Tools → CCMS → Spool →

Spool Administration;在标签条Admin.中选择Settings → Admin. → Automatically删除过去的打印请求。）如果两种函数同时执行，他们将导致数据库的
严重错误。更多信息参见SAP Note 498668 (SAP R/3 4.6A – 4.6B, 4.6C – 4.6D, SAP Web AS 6.10 – 6.40)。
Q&A

讨论
达美信息技术有限公司
www.dimension-infotech.com