简介：本资源是一份面向SAP BASIS运维工程师及初学者的系统化日常操作指南，聚焦权限管理、集团维护、数据库巡检、后台作业监控、打印配置、系统性能分析与传输管理等核心运维场景，助力快速掌握生产环境下的标准化操作与排错要点。资源为单文件PDF格式，体积精简（2.02MB），内容源自科莱特SAP内训实录，涵盖SU01/SU10/PFCG等30余个高频事务码的用途说明、典型操作路径、日志定位方法及安全注意事项，如DB13数据库维护日历配置、SM37作业异常分析、ST06/ST03性能基线监控实践等。目前已有962人学习下载，内容结构清晰、术语准确、贴合一线运维实际，可作为日常速查手册、新员工培训材料或备考SAP Certified Technology Associate-Basis的重要补充资料。

1. SAP日常运维BASIS：不是装完就完事的“系统看门人”，而是7×24小时守着37个关键事务码的故障拦截员

你有没有遇到过这样的场景：凌晨2点，生产系统突然卡死，ST06显示CPU飙到98%，SM50里挂着十几个“ZREPORT_LONGRUN”进程像幽灵一样不释放，ST22里堆了17个ABAP短dump，而DB12日志里昨夜的备份任务赫然标着“FAILED”——但没人知道它为什么失败，因为没人定期翻看/usr/sap/trans/log/下的DEPLOY.LOG。这不是电影桥段，是某高校SAP实验室运维同学的真实夜班记录。SAP BASIS日常运维，从来不是“配好参数、建好用户、跑通传输”就交差的事；它是用SU01、SM37、DB02、ST22等37个核心事务码织成的一张实时响应网，覆盖权限、作业、数据库、锁、更新、打印、日志七大故障高发区。它不考你能不能从零装一套ECC6，而考你能否在SM12里一眼识别出被ALV报表意外锁住的VBAP表条目，在SU53里反向追踪出哪个角色漏配了S_TCODE导致用户点开FICO模块直接报授权失败，在DB02中发现DD03L索引碎片率超65%并预判三天后查询将变慢3倍。这份资料不是入门指南，而是某公司BASIS团队把三年高频故障、误操作、日志盲区浓缩成的“值班手册”——它默认你已能登录GUI，目标是让你第二天早会前，就能独立完成一次完整巡检闭环。

2. 用户权限与集团管理：从SU01解锁账号到SCC4创建集团，权限链断裂比数据库宕机更难定位

SAP权限体系不是扁平的“给用户打勾”，而是一条由用户→角色→权限对象→字段值→事务码构成的脆弱链条。任何一环松动，都会导致“用户能登录但点不开FI模块”这类玄学问题。日常运维中，80%的权限类工单其实源于角色配置疏漏或传输未同步，而非用户本身异常。

2.1 SU01实操：不止是改密码，更是权限继承的起点

SU01常被当成“重置密码工具”，但它真正的价值在于权限复用设计。例如，为新入职财务专员创建账号FIN001时，不应手动勾选所有FI权限，而应复制已有合规账号FIN_MGR（需确保该账号角色已通过PFCG严格审计）：

* 在SU01界面操作路径： * 1. 输入用户名 FIN001 → 点击"Create" * 2. 勾选"Copy user data" → 输入源用户 FIN_MGR * 3. 关键步骤：取消勾选"Copy logon data"（避免密码策略冲突） * 4. 在"Roles"页签，手动移除FIN_MGR中冗余的CO权限（如S_CMM_...） * 5. 保存前务必点击"Check"按钮验证角色兼容性

提示：复制时若跳过“Check”步骤，可能引入角色冲突（如两个角色对同一事务码赋予不同授权对象），导致SU53检查时出现“Authorization check failed for object S_TCODE”却无法定位具体角色。

2.2 PFCG深度配置：绕过“全选式授权”的四个必填字段

PFCG创建角色时，新手常陷入“把所有事务码拖进角色就万事大吉”的误区。实际生产环境要求每个角色必须明确四个维度：

2.3 SCC4集团创建：三步验证法避免“集团不可见”黑洞

SCC4创建新集团（如CLNT800）后，常出现“用户登录显示空白集团列表”。这不是GUI缓存问题，而是集团未被正确注册到系统目录。必须执行三步验证：

1. SCC4内检查：创建后立即点击“Display” → 确认Client Role为Customizing且System Change Option为Modifiable；
2. SM51交叉验证：在SM51中查看所有应用服务器 → 确认CLNT800出现在各服务器的“Client List”列（若缺失，说明集团未广播到集群）；
3. OS层确认：登录Linux服务器，执行：

# 检查集团目录是否存在（SID为D01示例） ls -l /usr/sap/D01/SYS/global/client/800/ # 应返回 profile/、sec/、data/ 三个目录 # 若无data/目录，需手动运行：sapcontrol -nr 00 -function CreateClientData 800

注意：SCC4中Client Role选错会导致后续传输失败——Customizing集团可接收开发请求，Production集团仅接受测试请求，混用将触发STMS队列阻塞。

2.4 SU53权限诊断：从“报错页面”反向定位缺失对象

当用户执行FB60报错Authorization check failed for object S_TCODE，不要急着加权限。先用SU53捕获真实缺失项：

1. 用户在FB60页面按Ctrl+Shift+F12（或菜单System → User Profile → Own Data → Authorizations → Authorization Check）；
2. 执行任意操作（如输入凭证号）→ 系统弹出SU53窗口；
3. 关键动作：点击右上角“Analysis” → 查看“Missing Authorization”标签页；
4. 此处会精确显示缺失的Object: S_TABU_DIS, Field: AUTH = 'DISP', Value: 'VBAP'（而非笼统的S_TCODE）。
   此时应在PFCG中为对应角色添加S_TABU_DIS对象，并设置AUTH=DISP+DICBER=SD（非VBAP字面值），因DICBER才是控制SD模块表访问的正确字段。

2.5 避坑：权限与集团管理的五个血泪现场

• 现象：SU10批量修改用户后，部分用户登录报Invalid user type
  原因：批量导入Excel时，User Type列填写了Dialog但未同步更新Logon Data页签的Initial Password字段（系统强制要求Dialog用户必须有初始密码）
  解决：在SU10导入模板中，User Type为Dialog时，Initial Password列必须填入符合密码策略的字符串（如Abc123!），且Validity Period需大于0

• 现象：SCCL拷贝集团后，新集团中自定义表数据为空
  原因：SCCL默认只拷贝字典结构（DDIC），不拷贝应用数据；未勾选Copy Application Data选项
  解决：在SCCL选择源集团后，点击Settings→ 勾选Copy Application Data→ 指定要拷贝的表名（如ZMM_INVOICE），避免全库拷贝导致超时

• 现象：PFCG保存角色时报Profile generation failed: No authorization to create profiles
  原因：当前用户缺少S_PROFC权限对象中的ACTVT=01（创建权限集）
  解决：用SU01为当前用户临时添加SAP_ALL角色（仅限调试），生成后立即移除，改用S_PROFC最小化授权

• 现象：SU01复制用户后，新用户无法执行SE38，但原用户可以
  原因：原用户角色中包含S_DEVELOP对象，其DEVCLASS字段值为$TMP（临时包），而新用户角色继承后该字段为空
  解决：在PFCG中编辑新角色 → 找到S_DEVELOP→ 点击Change Authorization Data→ 将DEVCLASS设为$TMP或具体开发包名

• 现象：SCC4创建集团后，SM51中看不到该集团，但SCC3日志显示创建成功
  原因：集团创建时System Change Option选为Not Modifiable，导致系统拒绝将其加入客户端列表
  解决：用SCC4重新编辑集团 → 将System Change Option改为Modifiable→ 重启所有应用服务器（sapcontrol -nr 00 -function RestartSystem ALL）

3. 数据库与后台作业监控：DB02看碎片率、SM37盯取消作业，让数据库自己“说话”

数据库不是黑匣子，DB02、DB12、BRTOOLS这些事务码和工具，本质是数据库向BASIS工程师发出的“健康预警电报”。同样，SM36/SM37也不是简单的“定时任务开关”，而是生产系统稳定性的压力传感器——那些被取消的作业，往往藏着未暴露的性能瓶颈。

3.1 DB02实战：从“表膨胀”到“索引失效”的三级诊断

DB02首页显示的Table Size只是表体积，真正致命的是Index Fragmentation（索引碎片率）。当DD03L（数据字典表）碎片率＞40%时，SE11打开任意表都会明显卡顿。诊断流程分三级：

1. 一级筛查（DB02 → Tables）：排序Fragmentation %列，标记＞30%的表（重点关注DD03L、TRDIR、TADIR）；
2. 二级分析（DB02 → Indexes）：选中高碎片表 → 点击Indexes页签 → 查看各索引Clustering Factor（聚集因子），若＞表行数的1.5倍，说明索引严重离散；
3. 三级修复（BRTOOLS）：

# 登录数据库服务器（以Oracle为例） su - ora<sid> # 进入BRTOOLS交互模式 brtools # 选择 1. Database utilities → 3. Reorganize database → 2. Rebuild index # 输入索引名：DD03L~0 # 确认重建（耗时约15分钟，需业务低峰期）

提示：重建索引前，务必用SELECT COUNT(*) FROM DD03L验证表数据完整性，避免重建过程中发生ORA-00600内部错误导致索引损坏。

3.2 DB12日志解析：从“备份成功”到“空间告警”的精准判断

DB12显示的“OK”不代表备份真正可靠。必须人工核查三处细节：

• 备份类型：确认日志中Backup type: online full（在线全备），而非online incremental（增量备），后者恢复时依赖全备基线；
• 归档日志：检查Archive log status: ACTIVE，若为INACTIVE，说明归档进程挂起，后续恢复将丢失最近事务；
• 空间预警：在DB12中点击Directory→ 查看/oracle/<SID>/oradata/路径剩余空间，当＜15%时，需立即清理/oracle/<SID>/archivelog/下7天前的归档（find /oracle/<SID>/archivelog -name "*.arc" -mtime +7 -delete）。

3.3 SM36/SM37联动：从“作业取消”反推系统瓶颈

SM37中状态为CANCELLED的作业，90%源于资源争抢。不能只删作业，要追根溯源：

1. 在SM37中双击取消作业 → 查看Job Log页签 → 复制Error Message（如TIME_OUT或NO_MEMORY）；
2. 根据错误类型，跳转至对应监控：
   • TIME_OUT→ 查ST06内存使用率，若Page Space＞90%，则需调大abap/shared_objects_size_MB参数（RZ10）；
   • NO_MEMORY→ 查SM50中DIA工作进程内存占用，若单进程＞2GB，需检查是否运行了未优化的ABAP报表（如SELECT * FROM VBAK未加WHERE）；
3. 关键技巧：在SM36定义作业时，强制设置Maximum Runtime（如00010000=1小时），避免长作业无限消耗资源。

3.4 BRTOOLS进阶：用brbackup命令行实现备份自动化

GUI的DB13只能调度固定任务，真正运维需要脚本化。以下为每日全备脚本核心逻辑：

#!/bin/bash # daily_full_backup.sh SID=D01 BACKUP_DIR="/oracle/${SID}/backup/full_$(date +%Y%m%d)" # 创建备份目录 mkdir -p ${BACKUP_DIR} # 执行在线全备（-u参数指定数据库用户） brbackup -u / -m full -d util_file -t online -f ${BACKUP_DIR}/full.bck # 验证备份完整性 brbackup -u / -m verify -f ${BACKUP_DIR}/full.bck # 清理7天前备份 find /oracle/${SID}/backup -name "full_*" -mtime +7 -exec rm -rf {} \;

参数说明：-m full指定全备模式；-d util_file表示使用文件系统备份（非磁带）；-t online启用热备；verify步骤不可省略，曾有案例因存储IO错误导致备份文件损坏但DB12仍显示“OK”。

3.5 避坑：数据库与作业监控的五个翻车现场

• 现象：DB02中DD03L碎片率92%，但重建索引后次日又升至85%
  原因：未关闭DDIC自动优化统计更新（DB13中UPDATE STATISTICS任务频繁刷新字典表）
  解决：在DB13中停用UPDATE STATISTICS任务 → 改为每周日凌晨手动执行brconnect -u / -f stats -t all

• 现象：SM37中作业状态为FINISHED，但业务方反馈数据未更新
  原因：作业输出日志（Spool）中存在Commit failed: lock timeout，但SM37默认不显示Spool内容
  解决：在SM37中选中作业 → 点击Job Log→ 切换到Spool页签 → 查看详细输出，定位锁表对象（如VBAP）

• 现象：BRTOOLS执行brbackup报错ORA-19571: archived log not found
  原因：归档日志路径在init<SID>.ora中配置为/oracle/<SID>/archivelog/，但实际归档写入/oracle/<SID>/arch/
  解决：用sqlplus / as sysdba执行ARCHIVE LOG LIST确认真实路径 → 修改init<SID>.ora中log_archive_dest_1参数

• 现象：DB12显示备份成功，但/oracle/<SID>/backup/目录下无文件
  原因：BRTOOLS配置文件init<SID>.sap中backup_root_dir指向了NFS挂载点，而NFS服务夜间中断
  解决：在init<SID>.sap中将backup_root_dir改为本地路径（如/oracle/<SID>/backup_local/），再软链到NFS

• 现象：SM36定义作业时，Start Condition设为Date/Time，但作业从未触发
  原因：服务器时区与SAP系统时区不一致（如服务器为CST，SAP配置为UTC）
  解决：在RZ10中检查system/time_zone参数 → 与OS层timedatectl status输出比对 → 不一致则统一为Asia/Shanghai

4. 系统监控与传输管理：ST06看资源水位、STMS管传输队列，让问题在爆发前“显形”

系统监控不是“每天点开ST06截图发邮件”，而是建立资源水位基线、识别异常模式、预判故障点。传输管理更不是“点点STMS按钮”，而是理解传输请求如何在跨系统间流动、为何卡在队列、怎样安全回退。这两者共同构成SAP运维的“神经中枢”。

4.1 ST06/ST03联合分析：从“CPU高”到“进程阻塞”的归因路径

ST06的CPU使用率只是表象，ST03的工作负载分析才是病因诊断书。典型归因路径：

1. ST06发现CPU Utilization持续＞85% → 切换到Process Overview页签，查看Top Processes；
2. 发现disp+work进程占CPU 70% → 进入ST03 → 选择Workload Analysis→ 时间范围设为“Last 2 Hours”；
3. 在Response Time图表中，定位峰值时段 → 点击Detail Analysis→ 查看Top Transactions；
4. 若SM37排第一，说明后台作业调度器自身成为瓶颈 → 检查SM37中是否有大量READY状态作业（积压）；
5. 若ZMM_PRICING排第一，说明定价报表存在性能问题 → 进入SE30跟踪其SQL执行计划，发现全表扫描MARA表。

提示：ST03中Average Response Time＞2000ms即为异常，但需对比历史基线——某系统正常值就是1500ms，突然升至1800ms已是恶化信号。

4.2 SM50进程治理：Kill进程前的三重确认清单

SM50中看到ZREP_LONG进程占用95% CPU时，别急着点Cancel。执行Kill前必须确认：

1. 用户确认：在SM50中双击进程 → 查看User字段，用SM04确认该用户是否在线（避免杀掉正在做月结的财务用户）；
2. 锁确认：点击Locks按钮 → 查看是否持有ENQUEUE_E071（传输锁）或ENQUEUE_VBAP（业务表锁），若有则需先解锁；
3. 日志确认：在Process Details中查看Program字段 → 若为RSBTCDEL（后台作业删除程序），说明它正在清理历史作业，杀掉将导致作业元数据损坏。
   只有三重确认均通过，才执行Cancel，并立即在SM21中记录操作日志：“2023-10-05 02:15 CANCEL ZREP_LONG (PID 12345) due to CPU overload, notified user FIN001”。

4.3 STMS传输队列：从“请求未释放”到“跨系统同步失败”的排查树

STMS中传输请求卡在Import Queue，常见于跨系统场景。排查按树状展开：

• 根节点：检查源系统SE09状态
  若SE09中请求状态为Released，说明源系统已就绪；
• 第一层：检查目标系统STMS配置
  进入STMS →Overview → Systems→ 确认目标系统Status为Active且Transport Directory路径可写（ls -ld /usr/sap/trans/）；
• 第二层：检查传输日志
  查看/usr/sap/trans/log/下DEPLOY.LOG最新行，若含ERROR: Cannot connect to target system，说明SM59远程连接未配置；
• 第三层：验证远程连接
  进入SM59 → 选中目标系统连接 → 点击Connection Test→ 若失败，检查RFC Destination中Host是否为IP而非主机名（DNS解析失败常见）。

4.4 SE09传输请求管理：释放前的四步校验

SE09中释放传输请求（Release）是高危操作，必须执行四步校验：

1. 对象校验：双击请求 →Objects页签 → 检查Object Type是否含PROG（程序）、TABL（表）等高风险类型；
2. 变更校验：点击Changes按钮 → 查看Changed Objects列表，确认无SAP*开头的标准对象（禁止修改标准对象）；
3. 依赖校验：点击Dependencies→ 检查Dependent Requests是否为空，若有则需先释放依赖请求；
4. 日志校验：在Request Log中确认最后行为Successfully checked syntax of all objects（语法检查通过），而非Warning: Missing text elements（文本元素缺失，不影响但需记录）。

4.5 避坑：系统监控与传输管理的五个致命误区

• 现象：ST06显示Memory Utilization95%，但Free Memory仍有2GB
  原因：SAP内存管理机制中，Free Memory指未分配的物理内存，而Memory Utilization计算的是SAP工作进程使用的共享内存（abap/shared_objects_size_MB）占比
  解决：在RZ10中检查abap/shared_objects_size_MB参数值 → 若为4096MB且已用尽，则需调大至6144MB并重启实例

• 现象：SM50中进程状态为HELD，但无法Cancel也无法Resume
  原因：该进程正等待数据库锁（如ENQUEUE_E071），而锁持有者进程已崩溃但锁未释放
  解决：用ps -ef | grep disp+work找到SAP实例PID → 执行sapcontrol -nr 00 -function StopService强制终止实例 → 重启后锁自动释放

• 现象：STMS中传输请求状态为Importing，但持续2小时无进展
  原因：目标系统tp工具版本低于源系统（如源为7.53，目标为7.22），导致tp import命令不兼容
  解决：在目标系统执行tp version确认版本 → 若偏低，需升级SAP kernel（sapcar -xvf SAPEXE.SAR）

• 现象：SE09释放请求后，目标系统STMS队列中无该请求
  原因：源系统tp参数TP_DOMAIN_<SID>未指向正确的域控制器（Domain Controller）
  解决：在源系统/usr/sap/trans/bin/TP_DOMAIN_<SID>文件中，确认DOMAIN_SERVER指向域控制器主机名（非IP）

• 现象：SM21系统日志中大量W: Transaction was cancelled by user，但用户称未操作
  原因：后台作业RSBTCDEL（作业清理）自动取消了超时作业，日志级别设为Warning而非Info
  解决：在RZ10中将rdisp/wp_ca_blk参数从1改为0（禁用自动取消），改由人工在SM37中处理

5. 日志分析与故障闭环：从/usr/sap/<SID>/DVEBMGS00/work/的dev_w0到ST22的短dump，构建分钟级响应链

日志不是故障发生后的“考古现场”，而是实时流淌的系统脉搏。dev_w0（工作进程日志）、dev_disp（调度进程日志）、trans.log（传输日志）这三类文件，配合ST22、SM21等事务码，能将故障定位时间从小时级压缩到分钟级。关键在于建立日志关键词索引和自动化告警。

5.1 进程日志（dev_w0）：定位ABAP程序崩溃的第一现场

/usr/sap/<SID>/DVEBMGS00/work/dev_w0是ABAP工作进程的核心日志，每行以时间戳+进程ID开头。当用户报“执行ZMM_PO_CREATE卡死”，立即查此文件：

# 查找最近10分钟的ERROR行 tail -n 1000 /usr/sap/D01/DVEBMGS00/work/dev_w0 | grep -i "error\|exception\|dump" # 典型输出： # *** ERROR => ThRqWaitForRq: wait for request failed [thxxrd.c 11221] # *** ERROR => DpRqPutIntoQueue: put request into queue failed [dpxxdisp.c 12345] # *** ERROR => ThTaskHandler: task handler error [thxxtask.c 6789]

逻辑说明：ThRqWaitForRq错误表明工作进程无法从队列获取新请求，根源常是dev_disp调度进程异常；DpRqPutIntoQueue错误则说明调度进程无法将请求放入队列，需立即检查dev_disp日志。

5.2 启动日志（/home/ adm）：诊断实例无法启动的黄金线索

实例启动失败时，startsap命令只返回模糊提示。真正线索在/home/d01adm目录：

• std_server00.out：记录disp+work进程启动输出，含Kernel version: 753等关键信息；
• dev_icm：ICM（Internet Communication Manager）日志，若含Failed to bind to port 8000，说明端口被占用；
• dev_ms：消息服务器日志，若含MS: no free work process available，说明工作进程数不足。
  快速诊断命令：

# 检查端口占用（以8000端口为例） netstat -tuln | grep :8000 # 若被占用，查进程PID lsof -i :8000 # 杀掉占用进程（谨慎！） kill -9 <PID>

5.3 ST22短dump分析：从“SYSTEM_NO_ROLL”到“DBIF_RSQL_SQL_ERROR”的归因

ST22中SYSTEM_NO_ROLL（系统无法回滚）dump最常见，但90%源于数据库连接问题。分析步骤：

1. 在ST22中双击dump → 查看Short dump analysis→ 定位What happened?字段；
2. 若为SYSTEM_NO_ROLL，点击Source Code页签 → 查看报错行附近代码（如EXEC SQL COMMIT.）；
3. 切换到Database Interface页签 → 查看DB Error Text，若为ORA-03113: end-of-file on communication channel，说明Oracle实例已宕；
4. 终极验证：在数据库服务器执行sqlplus / as sysdba→SELECT status FROM v$instance;，若返回MOUNTED而非OPEN，确认Oracle宕机。

5.4 自动化日志监控：用shell脚本实现分钟级告警

人工翻日志效率低下，以下脚本每5分钟扫描关键日志，发现ERROR立即邮件告警：

#!/bin/bash # log_monitor.sh LOG_DIR="/usr/sap/D01/DVEBMGS00/work" ALERT_FILE="/tmp/log_alert_$(date +%H%M)" # 检查dev_w0中最近100行ERROR if tail -n 100 ${LOG_DIR}/dev_w0 | grep -q "ERROR"; then echo "$(date): ERROR in dev_w0" > ${ALERT_FILE} # 发送邮件（需配置mailx） mailx -s "SAP Alert: dev_w0 ERROR" admin@company.com < ${ALERT_FILE} fi # 检查trans.log中失败传输 if tail -n 100 /usr/sap/trans/log/DEPLOY.LOG | grep -q "ERROR:"; then echo "$(date): ERROR in DEPLOY.LOG" >> ${ALERT_FILE} mailx -s "SAP Alert: DEPLOY.LOG ERROR" admin@company.com < ${ALERT_FILE} fi

参数说明：tail -n 100限制扫描范围避免性能损耗；grep -q静默匹配；mailx需提前配置SMTP（/etc/mail.rc中设set smtp=smtp://smtp.company.com:25）。

5.5 避坑：日志分析与故障闭环的五个认知陷阱

• 现象：ST22中dump类型为DBIF_RSQL_SQL_ERROR，但DB02显示数据库一切正常
  原因：该错误常因ABAP程序中SELECT语句未加UP TO 100 ROWS限制，导致一次性读取百万行触发数据库内存溢出，而非数据库本身故障
  解决：在SE38中打开报错程序 → 定位SELECT语句 → 添加UP TO 100 ROWS或改用SELECT ... INTO TABLE itab UP TO 100 ROWS

• 现象：dev_w0日志中大量ThTaskHandler: task handler error，但SM50中进程状态正常
  原因：该错误多由Java Connector（JCo）调用超时引发，与ABAP进程无关，需检查jcoDestination配置中的peakLimit参数
  解决：在RZ10中搜索jco/destination/peakLimit→ 将默认值10调大至50

• 现象：/home/d01adm/std_server00.out中显示Kernel version: 753，但disp+work进程不启动
  原因：std_server00.out仅记录启动命令输出，真正失败在dev_disp日志中，若含DpLoadProfile: cannot open profile file，说明DEFAULT.PFL路径错误
  解决：检查/usr/sap/D01/SYS/profile/下是否存在DEFAULT.PFL，若无则从备份恢复

• 现象：trans.log中DEPLOY.LOG显示Import successful，但目标系统中程序未更新
  原因：传输请求中对象类型为PROG（程序），但目标系统rdisp/wp_no_btc参数为0（禁用后台工作进程），导致程序未激活
  解决：在目标系统RZ10中将rdisp/wp_no_btc设为1，重启实例后手动执行SE01激活程序

• 现象：SM21中系统日志显示W: ICM: connection closed by peer，但网络连通性测试正常
  原因：该警告源于客户端（如浏览器）主动断开连接（用户关浏览器），非服务器故障，属正常现象
  解决：在SM21中过滤Type = E（Error）日志，忽略Type = W（Warning）日志，避免误报

6. 运维习惯固化：从“救火队员”到“系统医生”，我的三件套检查清单与每日15分钟巡检法

从业务部门打来电话说“系统慢”，到定位出是DD03L索引碎片率89%导致SE11卡顿，我经历过从手忙脚乱到胸有成竹的转变。这个转变不是靠背熟37个事务码，而是靠把高频故障场景固化成肌肉记忆。现在我的电脑桌面永远开着三个终端窗口：一个连着生产系统GUI，一个连着Linux服务器，一个开着日志监控脚本。每天早会前15分钟，我雷打不动执行这套检查，它让我在问题爆发前就嗅到异常。

6.1 三件套检查清单：15分钟覆盖70%故障场景

这三件事耗时不到15分钟，却能拦截绝大多数生产事故：

1. DB02碎片率快照：
   • 进入DB02 →Tables页签 → 排序Fragmentation %→ 记录DD03L、TRDIR、TADIR三张表的碎片率；
   • 阈值红线：DD03L＞40%、TRDIR＞30%、TADIR＞25% → 当日安排重建；
2. SM37作业积压扫描：
   • 进入SM37 →Selection中Status选READY→ 执行 → 查看结果数；
   • 阈值红线：READY作业＞5个 → 立即检查SM66中DIA进程内存占用，若＞1.5GB则重启工作进程；
3. ST22短dump清零：
   • 进入ST22 →Selection中Date设为“Today” →

本文还有配套的精品资源，点击获取