简介一份面向Oracle数据库运维人员与初学者的日常管理与维护课件按照真实运维场景系统梳理了实例的启动与关闭、数据库日常检查与维护、企业管理器管理、RAC数据库日常操作、紧急故障处理等内容。课件从实例启动的Nomount、Mount、Open三个阶段和关闭数据库的NORMAL、TRANSACTIONAL、IMMEDIATE、ABORT四种模式讲起随后展开日志检查、性能、存储与安全检查方法并专门介绍RAC高可用环境下的操作要点及alertSID.log、后台跟踪文件、用户跟踪文件等诊断文件的管理技巧。整套资料仅包含1个PPT文件大小1.83MB结构紧凑、重点突出可作为Oracle DBA日常运维的速查手册或培训教材。已有98人学习下载适合需要快速掌握Oracle核心维护流程的数据库工作者。1. Oracle日常管理与维护先建立巡检习惯再谈调优接手一套Oracle生产库第一周通常不是忙着调参数而是把手里的检查动作固定下来。日常管理与维护这件事说到底就是两句话每天知道实例活着每周确认备份能恢复。很多线上故障——表空间满了、归档写不进去、监听悄悄断掉——都不是突发而是巡检缺失后的必然结果。这套工作并不神秘也不需要多高深的技巧靠的是稳定的节奏和几条靠谱的SQL。这篇笔记按一线DBA的工作流把巡检清单、RMAN备份、性能定位和故障排查串成一条可以直接落地的路径写给刚接手Oracle实例的运维也写给想把零散经验整理成体系的人。2. 日常巡检体系从实例状态到表空间增长的检查清单管理Oracle库最先要建立的不是某个高深工具而是节奏。巡检的价值在于把异常窗口缩到最小表空间使用率从80%涨到95%通常不是一天的事如果每周才看一次可能正好错过加数据文件的时间。下面这套节奏是生产环境常用的一套按天、周、月拆开配合几条稳定的SQL基本能覆盖日常的大部分风险。2.1 巡检节奏每天、每周、每月分别盯什么巡检最怕两件事做得太勤但没重点或者想起来才做。我习惯把检查按频率拆成三档频率检查对象常见手段每天实例状态、告警日志、监听进程、磁盘空间sqlplus 查 gv$instancetail alert 日志每周表空间使用率、归档日志量、RMAN 备份结果表空间使用率 SQLv$rman_backup_job_details每月AWR 报告、等待事件趋势、锁与长事务awrrpt.sql、v$session / v$transaction每天的动作应该轻量5 分钟内能看完重量级的分析放到周末执行。这里有个容易被忽略的细节监听状态和磁盘空间属于操作系统层面的检查很多 DBA 只盯数据库内部结果数据库本身正常磁盘被归档日志或监听日志写满反而拖垮整个实例。等级保护测评时常用的检查命令其实也是从这个层面开始的——先看进程、再看磁盘、最后验证审计开关顺序不能乱。2.2 实例状态与告警日志每天五分钟的基础检查每天第一件事是确认实例还在预期状态。登录进去看 gv$instance 是最稳的做法一条 SQL 就能看到实例名、状态和数据库状态-- 实例状态巡检看到 OPEN 才算正常 SELECT inst_id, instance_name, status, database_status, version FROM gv$instance;这条命令返回的 status 列是数据库实例的运行模式正常应该是 OPENdatabase_status 是 ACTIVE。如果看到 STARTED 或 MOUNTED说明实例没完全打开应用侧肯定连不上。INSTANCE_NAME 在多实例环境RAC下尤其要留意别把节点看混了。版本号顺手记一眼升级和打补丁时用来核对当前基线。接着看告警日志。Oracle 的 alert 日志记录了从启动参数到 ORA- 错误的所有关键事件是每天必翻的黑匣子# 告警日志路径因版本而异11g 通常在 diag/rdbms/dbname/sid/trace 下 tail -200 $ORACLE_BASE/diag/rdbms/orcl/orcl/trace/alert_orcl.log看完尾部 200 行基本能判断前一天夜里有没有 ORA- 报错、有没有做自动维护任务。重点找这几类内容ORA- 开头的错误号、伴随着的进程终止信息、以及 unexpected end of redo stream 这样的异常退出记录。出现 ORA-01555 或 ORA-01688 这种与空间相关的错误当天就要处理拖过夜大概率会演变成应用故障。这个动作别看简单很多故障的早期信号都藏在里面。2.3 表空间使用率每周必跑的SQL表空间写满会让业务直接报错但它是所有故障里最好预防的一种。每周跑一次使用率统计把超过 90% 的提前加数据文件就能避掉大部分磁盘类故障。核心 SQL 是这样写的-- 表空间使用率统计超过 90% 重点标注 SET LINESIZE 200 COL tablespace_name FORMAT A30 SELECT b.tablespace_name, ROUND((a.total_bytes - b.free_bytes) / a.total_bytes * 100, 2) AS used_pct, ROUND(b.free_bytes / 1024 / 1024, 2) AS free_mb, ROUND(a.total_bytes / 1024 / 1024, 2) AS total_mb FROM (SELECT tablespace_name, SUM(bytes) AS total_bytes FROM dba_data_files GROUP BY tablespace_name) a, (SELECT tablespace_name, SUM(bytes) AS free_bytes FROM dba_free_space GROUP BY tablespace_name) b WHERE a.tablespace_name b.tablespace_name ORDER BY used_pct DESC;这里要补充一个容易踩的细节dba_free_space 统计的是数据文件内部剩余空间它不会考虑自动扩展AUTOEXTEND的文件大小变化。也就是说一个开启了自动扩展的表空间即使 used_pct 显示 99%只要磁盘还有余量它还能涨。反过来磁盘快满时dba_free_space 可能还剩不少实际写入却因为磁盘空间不足而失败。所以没看磁盘使用率就看表空间使用率是很多人翻车的点。表空间在 90% 左右就该规划加数据文件别等到 98% 再动手生产环境加文件要花时间业务高峰窗口还不一定允许操作。2.4 归档日志与备份结果两条容易被轻视的状态检查归档日志是备份恢复的基础但它也是磁盘杀手。每天产生的归档量决定了磁盘占用也决定了 RMAN 备份策略里需要保留多少文件。检查归档生成的节奏-- 查看最近7天每天产生的归档日志量 SELECT TRUNC(first_time) AS day, COUNT(*) AS archivelog_count, ROUND(SUM(blocks * block_size) / 1024 / 1024) AS size_mb FROM v$archived_log WHERE first_time SYSDATE - 7 GROUP BY TRUNC(first_time) ORDER BY day;如果发现某天归档量突然成倍增长通常意味着业务高峰期有大批量事务或者有异常会话在反复提交。另一个需要确认的是定期清理策略否则归档目录会无声无息地涨满。备份检查放到每周看的是 RMAN 任务有没有成功结束-- 最近一次备份是否完成 SELECT start_time, end_time, status, input_bytes/1024/1024 AS input_mb FROM v$rman_backup_job_details WHERE start_time SYSDATE - 7 ORDER BY start_time DESC;status 列是 COMPLETED 才算正常。如果看到 FAILED 或 RUNNING 停了很久先查 v$session 里有没有卡住的 rman 会话再去看 rman 日志。备份失败常见原因有三个磁盘空间不够、归档目录满了、或者目标库连接串有问题。按这个顺序排查大多数问题能在十分钟内定位。3. 备份与恢复RMAN策略设计、备份脚本与恢复验证日常管理做得再好备份恢复这一关过不了前面全是白干。Oracle 的备份工具五花八门但从 10g 到现在RMAN 始终是主流选择。它能把全备、增备、归档备份、控制文件备份统一到一个管理通道里而且支持备份验证和恢复演练这是冷备脚本完全比不了的。这一章按备份策略设计、脚本落地、恢复验证三步走讲透一套够用的备份体系。3.1 备份策略的三个前提归档模式、保留策略、备份计划第一个前提是数据库必须跑在归档模式下。非归档模式下 RMAN 只能做一致性备份恢复时最多恢复到备份点中间所有提交都会丢这是不能接受的。确认是否开启归档-- 查询归档模式状态 ARCHIVE LOG LIST;如果显示 No Archive Mode需要停机做模式切换。常见做法是先把数据库干净关闭再启动到 mount 状态执行 ALTER DATABASE ARCHIVELOG最后正常打开。这件事必须在业务低峰期做而且做完立刻补一次全备。第二个前提是保留策略。RMAN 里最常见的设定是恢复窗口RECOVERY WINDOW比如保留 7 天意思是任何时刻都能恢复到 7 天内的某个时间点。配置很简单CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;恢复窗口和备份频率是配套的窗口越长需要保留的备份集越多磁盘占用越大。新环境我一般从 7 天起步跑两周观察备份集大小再决定要不要加密或者压缩。第三个前提是备份计划。全备加增量是性价比最高的组合周末做全备工作日做增量归档日志每天备份这个节奏在大多数生产系统里够用。3.2 一套可复制的RMAN备份脚本RMAN 的命令写在脚本里执行比在命令行手工敲更可靠也方便加日志和告警。下面是一套在生产环境能直接改用的备份脚本框架#!/bin/bash # 每日增量备份 归档日志备份失败时退出非零状态码 export ORACLE_HOME/u01/app/oracle/product/11.2.0/dbhome_1 export ORACLE_SIDorcl export PATH$ORACLE_HOME/bin:$PATH export DATE$(date %Y%m%d) rman target / log/u01/backup/logs/rman_${DATE}.log EOF RUN { ALLOCATE CHANNEL c1 TYPE DISK; BACKUP INCREMENTAL LEVEL 1 DATABASE PLUS ARCHIVELOG DELETE INPUT; BACKUP CURRENT CONTROLFILE; RELEASE CHANNEL c1; } DELETE NOPROMPT OBSOLETE; EOF if [ $? -eq 0 ]; then echo $(date) RMAN backup succeeded /u01/backup/logs/rman_history.log else echo $(date) RMAN backup FAILED, check rman_${DATE}.log /u01/backup/logs/rman_history.log exit 1 fi这段脚本里几个关键点INCREMENTAL LEVEL 1 是增量备份只备份自上次备份以来变化的块比全备快得多PLUS ARCHIVELOG DELETE INPUT 会在备份的同时把归档日志一起备份成功写入备份集后自动删除磁盘上的归档文件既保证恢复完整性又能控制归档目录大小DELETE OBSOLETE 配合前面设置的 7 天恢复窗口自动清理过期备份集。我第一次用这个脚本时忘了加 DELETE INPUT结果归档日志涨到把磁盘塞满备份失败又连锁触发告警折腾了半个晚上才清干净。RMAN 备份日志要保留至少两周因为有些问题是延迟暴露的——比如备份集校验通过但两周后发现某份日志缺失这时候还得靠历史日志定位哪一天的备份出了问题。3.3 恢复验证平时不演练出事就翻车备份的真正价值只有在恢复时才能体现。很多团队做了大半年备份从没验证过是否能恢复真出事后发现归档日志少了一段或者恢复路径配置错了那时候说什么都晚了。验证恢复的最稳妥做法是定期在一台独立的测试服务器上做恢复演练还原一份备份出来然后做一致性检查。# 在测试机上验证备份文件是否可读不真正恢复 rman target / catalog / EOF RESTORE DATABASE VALIDATE; EOFRESTORE DATABASE VALIDATE 会读取所有备份集并校验其完整性但不实际写文件。这个动作能发现备份文件损坏、块校验失败等问题适合每周跑一次。真正的恢复演练建议每月做一次在测试环境执行 STARTUP NOMOUNT、RESTORE CONTROLFILE、RESTORE DATABASE 到某个时间点最后 OPEN RESETLOGS整个过程模拟一次完整故障恢复。恢复演练最核心的意义在于暴露人和流程的问题——比如测试环境缺了一个数据文件目录或者脚本写死了生产路径。我经历过一次把生产路径写死在恢复脚本里导致测试环境恢复时一直提示文件不存在查了半小时才发现是路径变量没有抽象出来。多做几次演练后脚本和环境配置会越来越接近真实可用的状态。4. 性能问题定位AWR报告、等待事件与SQL优化巡检保证系统稳定备份保证不丢数据但系统慢、接口超时、某个页面转圈半分钟这些性能问题才是日常运维里最消耗精力的事。性能定位的难点不在工具少而在信息太多会话几百个、SQL成千上万条、指标数不胜数。有效的路径是先从 AWR 报告拿到整体画像再落到特定等待事件最后精确定位到 SQL 和对象。这一章按这个顺序展开。4.1 什么时候该生成AWR生成后先看哪几页AWR 报告不是每天都看的通常是在性能明显下降、或者每周固定做一次趋势分析时生成。生成 AWR 需要两个快照 ID用 awrrpt.sql 脚本交互式生成即可# 以 sysdba 身份执行按提示输入快照范围 sqlplus / as sysdba $ORACLE_HOME/rdbms/admin/awrrpt.sql快照 ID 要先确认时间范围。比如怀疑昨天下午 3 点到 5 点系统慢就找覆盖这个区间的两个快照-- 查看现有快照确定时间范围对应的 SNAP_ID SELECT snap_id, begin_interval_time, end_interval_time FROM dba_hist_snapshot WHERE begin_interval_time SYSDATE - 2 ORDER BY snap_id;拿到 AWR 报告后不建议从头翻到尾按这个顺序看就够了第一页的 Instance Efficiency 看整体命中率Top 10 Foreground Wait Events 看等待事件排名SQL Statistics 按逻辑读或物理读排序基本能锁定可疑 SQL。Elapsed Time 与 CPU Time 的比例如果大于 2说明大量时间耗在等待而非执行优先去查等待事件。如果 CPU Time 占比很高则多半是 SQL 本身写得低效。4.2 三个最常见的等待事件怎么认、怎么对症等待事件是 Oracle 性能报告里最直白的线索。生产环境反复出现的通常就三类日志写等待 log file sync 和 log file parallel write本质是提交事务时等待日志写入磁盘。出现在高并发小事务场景下常见诱因是频繁提交、或者日志文件所在的磁盘 IO 能力不足。可以先查一下业务代码里是不是有循环里逐条提交的习惯这比折腾存储更值得优先处理。单块读等待 db file sequential read通常对应索引扫描或唯一键查找。如果这个等待占比很高先看对应 SQL 的执行计划是不是走了全表扫描而不是索引或者索引失效导致本该走索引的操作退化成了逐块读。缓冲区忙等待 buffer busy waits说明多个会话在竞争同一个内存块常见于热点数据块或刚刚插入的右侧块。这时候先确认是否是某张表的高并发插入集中在同一个数据块上比如 ID 单调递增的同时又有大量并发写。等待事件解决思路是先确认时间花在了哪里再判断是 SQL 问题、并发问题还是 IO 问题。很多新手一看到 db file sequential read 就想加索引但有时候问题出在过度索引导致大量小块读反而优化错了方向。4.3 SQL优化从执行计划到索引选择的落地方法定位到具体 SQL 后执行计划是判断优化方向的最终依据。在 SQL 前面加 EXPLAIN PLAN FOR 再查执行计划是最直接的验证手段EXPLAIN PLAN FOR SELECT o.order_no, o.amount FROM orders o WHERE o.order_status PENDING AND o.created_date SYSDATE - 1; SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);执行计划里重点看两个位置TABLE ACCESS FULL 表示全表扫描如果表数据量大而过滤条件能命中索引这通常就是性能瓶颈另一个是 NESTED LOOP 驱动表的顺序小表驱动大表效率更高。计划后面那几列 Cost 和 Rows 也要看Rows 如果和实际行数差出几个数量级说明统计信息过期先做一次表统计信息更新比加索引更治本-- 表统计信息过期会导致执行计划严重偏离真实情况 EXEC DBMS_STATS.GATHER_TABLE_STATS(OWNNAME APP, TABNAME ORDERS, CASCADE TRUE);索引的选择上我吃过不少亏最后总结出一条经验单列索引看选择性复合索引看查询模式的列顺序。比如 PENDING 状态只有少数记录但 created_date 是范围内查找复合索引把 created_date 放前面通常更有效。还有一个容易被忽略的场景分页查询在大偏移量时性能骤降不是因为索引缺失而是因为 Oracle 的分页写法让前 N 页的数据全部参与排序。11g 之后用 OFFSET 语法能优雅解决但老版本库上还是得靠 ROWNUM 嵌套写法规避大偏移量问题。遇到存储过程里面的动态 SQL还要格外注意绑定变量一旦拼字符串进去每次执行都变成硬解析执行计划经常走错路径。5. 常见故障排查监听、日志与归档空间那些埋过的坑前几章讲的是按部就班的日常管理但真正让 DBA 成长的永远是半夜被电话叫起来处理故障的那几次。这里把生产环境里最常见的几类故障整理出来每条按现象、原因、解决三个部分说清楚。这些坑每个都真实存在解决思路也是业内普遍认可的做法照着排查能少走很多弯路。5.1 监听服务无法启动端口与主机名的双重陷阱现象应用连接数据库报 ORA-12541 TNS no listener 或 ORA-12514lsnrctl status 提示 TNS-01169 或监听启动失败。Linux 环境下常见于重启后监听自动起不来Windows 服务里则表现为 oracle 监听服务无法启动服务状态一直停在已停止。原因排查分三步第一端口被占用比如 1521 被其他进程占了监听器根本绑不上第二主机名解析问题listener.ora 里配置的 HOST 与实际机器名不匹配或者 /etc/hosts 里主机名对应了 127.0.0.1远程连不上第三环境变量问题ORACLE_HOME 没加载导致监听器找不到配置文件。解决思路先检查端口占用netstat -tlnp | grep 1521如果有其他进程占用改 listener.ora 换端口或清掉占用进程。确认端口没问题后用 lsnrctl start 启动监听观察输出里报错的具体位置。hosts 文件的坑最隐蔽A 机器配了机器名对应的 127.0.0.1客户端走主机名连接时全被解析到本机回环连不上又不好排查。建议所有 Oracle 服务器把主机名解析指向真实内网 IP不要用 localhost。5.2 告警日志和监听日志无限增长磁盘被日志写满现象数据库整体变慢磁盘使用率告警检查后发现 $ORACLE_BASE/diag 或者 $ORACLE_HOME/network/log 目录占了几个 GBlistener.log 甚至到了几十 GB。应用日志里的错误五花八门但根源就是磁盘满。原因Oracle 默认把 listener.log 和 alert 日志无限制追加日积月累就成了磁盘杀手。特别是监听日志一个繁忙库一天就能写几百 MB几个星期不管就是几十 GB。很多运维首次接触时根本想不到一个纯文本日志能膨胀到 10GB 以上。解决先清理现有日志再配置轮转。监听日志的清理比较讲究直接删掉文件在某些版本上会导致监听器句柄失效需要先停监听再删。我在生产环境里验证过的做法是用 log.xml 配置轮转或者用 crontab 定期 truncate# 每天凌晨压缩并截断监听日志保留最近30天 0 2 * * * /usr/bin/find $ORACLE_HOME/network/log -name listener.log -mtime 30 -delete /dev/null 21 0 3 * * * /usr/bin/truncate -s 0 $ORACLE_HOME/network/log/listener.log这里有个细节要记住truncate 不会中断现有监听句柄而删除文件再重建会让监听器继续往已删除的 inode 里写磁盘空间永远释放不了。这就是为什么直接用 rm 清理 listener.log 经常发现空间没少的原因行政上总说“删了没效果”其实是删错了对象。告警日志的清理一般配合 ADRCI 的 purge 策略做设置保留 7 天比较合理。5.3 ORA-00257归档日志写满的连锁反应现象某个时间点后数据库应用更新全部报错 ORA-00257: archiver error前台只看到连接建立失败或事务停止部分场景表现为数据库虽然 open但内部事务无法提交。原因归档目录通常是 fast recovery areaFRA磁盘写满归档进程无法写入新日志数据库为防止数据丢失会挂起所有涉及写事务的操作。很多情况下前面的监听日志清理没做好空间被日志占掉归档目录还没到设置上限却已经物理写不进去。解决先清理旧归档文件再确认 FRA 配置-- 查看 FRA 使用情况 SELECT name, round(space_limit/1024/1024,2) AS limit_mb, round(space_used/1024/1024,2) AS used_mb FROM v$recovery_area_disk_usage;清理已经备份过的归档日志用 RMAN 而不是直接删文件避免破坏恢复链# 删除7天前已被备份过的归档释放FRA空间 rman target / DELETE ARCHIVELOG ALL COMPLETED BEFORE SYSDATE-7;清出空间后数据库通常能自动恢复写归档。如果还不行检查磁盘空间是否真的释放。用 RMAN 删归档是最安全的直接按文件删除会导致控制文件里的记录和实际文件对不上后面恢复必然翻车。日常上建议给 FRA 大小设置上限并配合监控FRA 使用率超过 85% 就触发告警80% 的时候最晚在一个工作日内处理。5.4 账户锁定与密码过期导致应用批量断连现象某天早上收到大批连接失败告警应用日志里报 ORA-28000 the account is locked 或者 ORA-28001 the password has expired。往往不是一个账户而是好几个服务账户同时出问题。原因Oracle 默认的 profile 里有密码有效期DEFAULT 为 180 天和失败登录次数限制到期或超限后账户自动锁定。生产环境的服务账户密码是应用配置里写死的基本没人会定期去改于是到时间点集中暴露。解决先临时解锁让业务恢复再调整密码策略。对于服务账户建议把密码过期关闭-- 创建无限期 profile 并分配给服务账户 CREATE PROFILE APP_SERVICE_PROFILE LIMIT PASSWORD_LIFE_TIME UNLIMITED FAILED_LOGIN_ATTEMPTS UNLIMITED; ALTER USER app_user PROFILE APP_SERVICE_PROFILE;手动账户则建议保留密码有效期但加一个提醒机制。还有一个隐藏坑某些版本下用 DBA 登录时也会触发密码过期检查如果 DBA 的密码过期会导致 DBA 无法登录这时候要先用操作系统认证进入数据库再处理。遇到应用批量断连的场景优先解锁而不是改密码改密码意味着要同步改所有应用连接配置恢复时间会拉长。6. 把巡检脚本交给crontab一套最小自动化方案前面几章的检查动作和排查命令如果全靠人工按时执行坚持两周容易坚持六个月基本不现实。落到最后我建议把重复的巡检动作收敛成一个脚本交给 crontab 去跑结果生成日志异常再通知人。这样日常管理就能从“记得去看”变成“系统帮你盯”。这个脚本不追求覆盖所有指标优先保证最关键的几项实例状态、表空间使用率、FRA 使用率、RMAN 备份状态。异常时输出告警信息可以把内容写到固定文件里让监控系统采集或者直接发邮件。下面是这套方案的最小版本#!/bin/bash export ORACLE_HOME/u01/app/oracle/product/11.2.0/dbhome_1 export ORACLE_SIDorcl export PATH$ORACLE_HOME/bin:$PATH export DATE$(date %Y%m%d%H%M) LOG_DIR/u01/dba/logs mkdir -p $LOG_DIR OUT_FILE$LOG_DIR/check_${DATE}.log sqlplus -s / as sysdba EOF $OUT_FILE SET FEEDBACK OFF SET PAGESIZE 100 PROMPT INSTANCE SELECT instance_name, status FROM v\$instance; PROMPT TABLESPACE SELECT tablespace_name, ROUND((total_bytes - free_bytes)/total_bytes*100,2) AS used_pct FROM (SELECT b.tablespace_name, (SELECT SUM(bytes) FROM dba_data_files WHERE tablespace_nameb.tablespace_name) total_bytes, free_bytes FROM (SELECT tablespace_name, SUM(bytes) free_bytes FROM dba_free_space GROUP BY tablespace_name) b) WHERE (total_bytes - free_bytes)/total_bytes*100 85; PROMPT ARCHIVE SELECT ROUND(SUM(blocks*block_size)/1024/1024,2) AS arch_mb_used FROM v\$recovery_area_disk_usage; EOF # 输出异常行单独汇总便于监控告警 grep -E DOWN|MOUNTED| 90 $OUT_FILE echo CHECK_ALERT: $OUT_FILEcrontab 里配置运行时间和日志轮转比如每工作日早上八点跑一次0 8 * * 1-5 /u01/dba/scripts/db_check.sh /dev/null 21这个脚本的核心价值不是写得漂亮而是稳定可预期。我见过很多团队把巡检脚本做得特别复杂收集几十个指标最后因为某个指标取数报错导致整个脚本挂掉连最基本的表空间检查都停了。简化以后即使某个指标出了问题也不影响其他检查项的产出。另一个教训是脚本里的输出一定带时间戳和实例名否则哪天多库混跑日志根本对不上号。归根结底日常管理与维护拼的从来不是单次操作有多精彩而是这套循环——检查、记录、处理、验证——能不能在半年一年里不间断地转起来。自动化承接的是重复动作人的精力留给那些真正需要判断力的事情。这套脚本方案可以根据实际环境扩展希望帮到你。本文还有配套的精品资源点击获取