简介《Oracle数据库运维案例介绍》PPT面向Oracle DBA、运维工程师及RAC学习者聚焦企业级数据库集群环境下的典型故障处理。内容以真实告警日志为主线详细拆解IPC Send timeout的成因分析LMS、LMD锁管理进程的职责阐述实例成员资格不一致时脑裂机制的判断方式以及ORA-29740错误导致的节点驱逐过程。同时结合netstat统计中的packet reassembles failed数据说明网络丢包、资源瓶颈对集群稳定性的影响并给出从日志分析、网络检查、资源监控到补丁排查的完整排错框架。资源为单个pptx演示文稿压缩包大小约1.83MB结构紧凑、图文结合适合已有一定Oracle基础、希望提升RAC故障诊断能力的工程师参考。目前已有133人学习浏览。1. Oracle 数据库运维案例怎么讲从报错截图到一张排查地图凌晨一点生产库报出 ORA-00257归档日志目录写满实例直接 hang 住——这个场景恰好就是《Oracle数据库运维案例介绍.pptx》里被反复复盘的那一类故障。值班同事翻遍手边的资料最后起作用的不是厚厚的官方文档而是半年前那份 PPT 里一条不起眼的排查顺序先查 V$ARCHIVED_LOG 确认哪些归档已经可以被清理再手动切一次日志最后用 rman 删除十分钟恢复。这套动作单独看每一行都简单真到生产环境才发现步骤顺序写反一次就是在业务高峰上多烧半小时。这份 PPT 讲的主题很具体把 Oracle 数据库运维中最常见的那几类故障还原成一张张可复用的排查地图。它不追求讲全数据库原理而是把每个案例拆成五个部分故障现象、影响范围、排查顺序、恢复动作、预防清单。适合正在亲手带 Oracle 库的一线运维工程师适合从开发转过来身兼 DBA 的同事也适合想在公司内部建一套运维知识库却不知道从哪下手的团队。真正值得投入的不是 PPT 的排版而是藏在案例背后的那条能在下一次翻车时救命的路径。2. 把案例讲成排查路径案例文档的骨架与四大分类2.1 从报错截图到故障树事件时间线先于一切很多人写运维案例习惯把报错截图往 PPT 里一贴再配两行说明文字就完事。读者看完只知道“哦发生过这件事”真要复现时连当时先敲了哪条命令都看不出来。我一般会把案例 PPT 固定成一条时间线记录一页只讲一个故障按时间点写下每个动作和结果。排障过程的时间线可以这样记录以归档满故障为例01:00 生产库报 ORA-00257实例 hang 住值班同事先跑 df -h确认 /oracle/archive 已满。01:03 业务完全不可用查 v$archived_log标记备份策略内可清理的归档定位可删除范围。01:10 用 rman 删除过期归档并执行 ALTER SYSTEM SWITCH LOGFILE 切换日志开始释放空间。01:20 数据库恢复正常业务恢复写入故障解除。时间线的价值不是记录“发生了什么”而是告诉后来的人“先做什么、后做什么”。报错截图只能证明当时报了什么错时间线能把当时的排查顺序还原成一套可倒推的动作序列。这条时间线本身就是一张故障树每个时间点都对应一个问题分支后来者照着记录走不需要重新发明排查过程。写的时候注意先写磁盘层确认df -h再写数据库视图定位v$archived_log因为磁盘是根因面视图是定位面顺序反了容易在已经明确的问题上绕圈。这份 PPT 的每一页最终都会沉淀成“现象—定位—动作”三步而不是一张孤零零的报错截图。2.2 案例分类表归档、表空间、监听、备份恢复四条线案例积累多了如果没有分类PPT 只会越堆越厚最后变成没人愿意翻的黑匣子。观察一线环境Oracle 数据库运维案例九成都在四条主线上归档日志、表空间、监听器、备份恢复。下面这张分类表可以作为知识库的第一版目录后续新案例先归到某一条线下再展开。故障类型典型报错首查对象常见恢复手段归档日志满ORA-00257v$archived_log、alert 日志、df -h切日志后用 rman 删除过期归档表空间不足ORA-01653 / ORA-01628dba_data_files、dba_free_space自包含扩容、增加数据文件监听器异常ORA-12541 / ORA-12514lsnrctl status、listener.log核对服务名、端口与防火墙备份恢复失败ORA-19809 / ORA-19815v$recovery_file_dest调整快速恢复区大小或备份保留策略为什么是这四类而不是其它归档满直接影响实例可用性表空间不足直接影响业务写入监听异常直接影响连接入口备份失败直接影响可恢复性。这四类故障各自对应一个日常巡检项把案例分类的最终目的是让每个案例都能反推出一条巡检规则——例如归档案例最终对应“每日检查磁盘空间与归档增长速率”。分类不要按错误代码分应该按“哪个环节破了”分因为同一个 ORA 报错可能来自完全不同的故障链。2.3 演练环境修改挂载路径后起不来空实例启动的正确姿势在某演练环境下称模拟项目 X里做磁盘挂载路径调整时遇到一个非常典型的坑数据盘从 /u01 改挂到 /u02操作系统层面一切正常但重启数据库后 startup 直接报 ORA-00210 找不到控制文件。很多人的第一反应是“控制文件是不是丢了”。其实控制文件还在只是数据库参数文件 spfile 里记录的 control_files 仍然指向旧路径 /u01/oradata/xxx/control01.ctl操作系统挂载路径变了参数文件里的字符串不会自动跟着变。这时候“怎么使用空实例启动”就是关键动作。空实例启动对应的是 startup nomount它只读参数文件不读控制文件也不碰数据文件所以即使控制文件路径已经失效实例也能先起来一小半给我们留出修正参数或重建控制文件的窗口。处理顺序应该是这样用 SHOW PARAMETER control_files 确认 spfile 里记录的控制文件路径在操作系统上确认控制文件在目标路径下是否真实存在用 startup nomount 把实例拉到空实例状态根据实际情况选择改 spfile 里的路径或者重建控制文件。-- 1. 先确认实例当前处于什么状态 SELECT instance_name, status FROM v$instance; -- 2. 确认参数文件里记录的 control_files 内容 SHOW PARAMETER control_files; -- 3. 在操作系统侧确认控制文件真的存在于新路径 -- 注意这里的 /u02/oradata/xxx 是模拟项目 X 的新挂载点 HOST ls -l /u02/oradata/xxx/control01.ctl /u02/oradata/xxx/control02.ctl这段 SQL 的逻辑是先看实例状态再比对该有的和实际有的。SHOW PARAMETER 读的是内存里的参数值也就是 spfile 实际加载进来的内容而不是操作系统文件里的文本这一点经常被忽略。如果控制文件在旧路径已经没有、新路径存在那么核心动作就是把 spfile 里的 control_files 参数改到新路径-- 修改 control_files 参数并生成新的 spfile ALTER SYSTEM SET control_files/u02/oradata/xxx/control01.ctl,/u02/oradata/xxx/control02.ctl SCOPESPFILE; SHUTDOWN ABORT; STARTUP;SCOPE 参数值得单独说明SCOPESPFILE 表示只写入 spfile不改变当前运行实例适合在实例已经被迫停掉、准备重新启动的场景。如果当前实例还能起来也可以用 SCOPEBOTH 同时改内存和 spfile。SHUTDOWN ABORT 是实例已经异常时的常用兜底关闭方式正常关闭优先用 SHUTDOWN IMMEDIATE。少数情况下控制文件真的丢了或者损坏了才需要走重建控制文件的最后手段。重建控制文件必须在 nomount 状态下执行并且数据库名必须与原库一致数据文件清单必须和磁盘上实际存在的文件一一对应多写或少写一个都会导致恢复失败-- 在 NOMOUNT 状态下重建控制文件数据库名为 xxx按实际环境替换 STARTUP NOMOUNT; CREATE CONTROLFILE REUSE DATABASE xxx NORESETLOGS NOARCHIVELOG MAXLOGFILES 16 MAXLOGMEMBERS 3 MAXDATAFILES 100 MAXINSTANCES 8 MAXLOGHISTORY 292 LOGFILE GROUP 1 /u02/oradata/xxx/redo01.log SIZE 200M, GROUP 2 /u02/oradata/xxx/redo02.log SIZE 200M DATAFILE /u02/oradata/xxx/system01.dbf, /u02/oradata/xxx/sysaux01.dbf, /u02/oradata/xxx/undotbs01.dbf, /u02/oradata/xxx/users01.dbf NO RESETLOGS;这段语句里的 LOGFILE 和 DATAFILE 条目必须从原库的 alert 日志或备份记录里逐个核对。重建控制文件属于高风险恢复操作不要在真实生产环境里直接照抄先在模拟项目 X 里把“参数修正优先、重建控制文件兜底”的两级路径跑通再把这页沉淀进案例 PPT。归档模式还牵扯到 RESETLOGS 的取舍演练环境如果改用了 NOARCHIVELOG会出现日志序列重置务必在案例里注明原始归档模式。3. 高频故障的排查顺序与常用命令先查什么后动什么排障最大的问题是“急”。业务在等领导在问手上只有一堆模糊的报错信息。Oracle 运维案例里最常见的一类教训就是动作顺序错明明只需要删几个归档结果把正在使用的日志一起删了明明要先确认服务名结果先重启了监听。这一章把四个高频案例的排查顺序固定下来每个案例都按“先查什么、后动什么”来写。3.1 归档日志目录满先确认后切换再删除归档满的第一直觉是“把老归档删掉”但直接在操作系统上 rm 是最危险的动作。归档文件和 redo 日志有关联直接物理删除不会同步更新控制文件里的记录轻则备份链断裂重则把正在使用的归档删掉导致实例异常。正确的顺序是先确认磁盘现状再确认哪些归档可以删切一次日志最后用 rman 删除。-- 先确认哪个目录快满了再从数据库侧找可清理的归档 SELECT sequence#, first_time, archived, deleted, backup_count FROM v$archived_log WHERE first_time SYSDATE - 1 ORDER BY sequence#; -- 强制切换日志让当前 redo 平稳落到归档 ALTER SYSTEM SWITCH LOGFILE;先查 v$archived_log 而不是直接删文件是为了拿到两个信息sequence# 的连续性以及 backup_count 是否大于零。归档是否可以被删除业务上通常看备份策略Oracle 侧则看它是否已经被备份过backup_count 为 0 的归档在 rman 删除时会被当作未受保护的日志处理需要谨慎。删除动作交给 rman 而不是操作系统rman target / DELETE ARCHIVELOG ALL COMPLETED BEFORE SYSDATE-7;rman 删除归档会自动同步控制文件里的记录这是它比 rm 可靠的根本原因。COMPLETED BEFORE SYSDATE-7 的含义是删除 7 天前完成的归档天数按备份保留策略调整如果只是想清掉已被备份过的旧日志可以改用 DELETE ARCHIVELOG BACKED UP 1 TIMES TO DEVICE TYPE DISK。不要在高峰期一次性删完所有归档保留最近一两天的日志避免 rman 恢复时找不到增量备份起点。3.2 表空间不足扩容前先看高水位和自包含ORA-01653 表示表空间没有可用空间业务写入被卡住。看到这个报错先别急着加数据文件先查两样东西现有数据文件是否还能自动扩展表空间里是不是有大对象长期占用高水位。-- 数据文件大小与自扩展情况 SELECT file_name, bytes/1024/1024 AS size_mb, maxbytes/1024/1024 AS max_mb, autoextensible FROM dba_data_files ORDER BY size_mb DESC; -- 表空间总使用率按使用率倒序 SELECT a.tablespace_name, ROUND((a.total_mb - NVL(b.free_mb,0)) / a.total_mb * 100, 1) AS used_pct FROM (SELECT tablespace_name, SUM(bytes)/1024/1024 AS total_mb FROM dba_data_files GROUP BY tablespace_name) a, (SELECT tablespace_name, SUM(bytes)/1024/1024 AS free_mb FROM dba_free_space GROUP BY tablespace_name) b WHERE a.tablespace_name b.tablespace_name() ORDER BY used_pct DESC;第一段 SQL 看 autoextensible 列如果已经是 ON说明库曾经在自动扩展但依然满了这通常意味着数据文件到了 maxbytes 上限或者磁盘真的没空间了如果是 OFF说明手动关闭了自扩展这是很多环境里表空间“突然满”的直接原因。第二段 SQL 把总大小和剩余空间拼在一起算使用率注意用 NVL 兼容免费空间为空的表空间。扩容时我一般会用 ALTER TABLESPACE 增加数据文件并开启自扩展ALTER TABLESPACE users ADD DATAFILE /u02/oradata/xxx/users02.dbf SIZE 8G AUTOEXTEND ON NEXT 1G MAXSIZE 32G;三个参数要配套看初始大小决定第一次分配多少空间NEXT 决定每次自动扩展的步长MAXSIZE 是硬顶。一次性给 32G 会让 rman 备份体积瞬间变大初始 8G 加 1G 步长是相对稳妥的起步值如果业务增速很快再调大 NEXT。不要对大表空间轻易做 RESIZE 缩小高水位之下无法回收空间会直接碰到 ORA-03297常见做法是用数据泵迁移或重建表来真正降高水位。3.3 监听器正常但连不上TNS 与防火墙的排查顺序有一种故障最让人头疼lsnrctl status 显示服务正常tnsping 也通但应用就是连不上报 ORA-12541 或 ORA-12514。这种“监听看着正常”的情况问题基本不在监听器本身而在注册信息或网络链路。先沿一条固定路径排查看监听日志是否收到客户端报文再看监听里注册的服务名再看客户端解析到的服务名最后看防火墙。# 查看监听状态与注册的服务 lsnrctl status lsnrctl services # 查看最近是否有客户端连接尝试 tail -n 50 $ORACLE_HOME/network/log/listener.log # 客户端侧测试网络可达性注意这里只测端口通不通 tnsping 服务名实际踩坑经验ORA-12514 多数时候是客户端 tnsnames.ora 里的 SERVICE_NAME 与数据库动态注册的服务名不一致大小写差异都能导致解析失败。ORA-12541 则是监听没有真正在监听端口常见原因是服务器防火墙只放行了 TCP 1521却没放行 Oracle 需要的其它端口或者监听进程被防火墙挡在外部。静态注册和动态注册的区别也值得在案例里写一笔动态注册依赖实例正常启动实例刚起来但注册还没完成时lsnrctl status 看不到服务应用就会立刻报连接失败等待几秒或手动执行 ALTER SYSTEM REGISTER 可以加快注册。3.4 Windows 环境安装 Oracle服务起不来的排查Windows 上装 Oracle 遇到的故障和 Linux 完全不同服务启动即停止最常见。先别动安装目录按服务层、端口层、日志层三步排查。# 查看 Oracle 相关服务是否已启动 net start | findstr /i oracle # 检查 1521 端口是否被占用或处于监听状态 netstat -ano | findstr 1521排查顺序是这样定的服务是数据库和监听器的宿主端口是连接入口事件查看器记录底层原因。常见原因有三类安装目录 NTFS 权限不足导致服务进程无法读取参数文件ORACLE_SID 环境变量和服务的 SID 不一致导致 sqlplus 找不到实例listener.ora 里端口被其它程序占用或写错。遇到服务“正在启动然后又自动停止”第一步应去 Windows 事件查看器里找 Oracle 服务的错误来源比盲目重启有效得多。Windows 下的数据库启动同样可以进命令行执行 sqlplus / as sysdba 然后 STARTUP如果命令行能起而服务起不来多半是服务的登录身份或路径配置问题和数据库本身没关系。4. 把巡检做成日常动作从手工 SQL 到轻量运维脚本案例 PPT 里最难沉淀的不是“当时怎么恢复的”而是“怎么让同类故障别再发生”。把案例变成日常巡检项是运维里最值得做的投入。4.1 每日巡检用一条 SQL 拼出关键指标看板值班巡检最怕的是漏看指标。与其查十几张动态视图不如把案例里最关心的几个指标拼成一张“一眼看板”每天定时跑一次输出成文本文件再交给监控系统去读。SELECT INSTANCE AS item, instance_name || / || status AS value FROM v$instance UNION ALL SELECT DB_TIME, to_char(current_scn) FROM v$database UNION ALL SELECT ARCHIVED_24H_CNT, to_char(COUNT(*)) FROM v$archived_log WHERE first_time SYSDATE - 1 UNION ALL SELECT TABLESPACE_FULL_CNT, to_char(COUNT(*)) FROM dba_data_files a WHERE a.autoextensible NO AND a.bytes/1024/1024 - NVL((SELECT SUM(b.bytes/1024/1024) FROM dba_free_space b WHERE b.tablespace_name a.tablespace_name), 0) 1024;这段 SQL 用 UNION ALL 把不同来源的指标拼成 item/value 两列方便按行解析。前三行分别回答实例活着吗、SCN 有没有推进、24 小时归档产生了多少最后一行统计 AUTOEXTENSIBLE 关闭且剩余空间不足 1G 的表空间数量。TABLESPACE_FULL_CNT 的判断条件是“不能自扩展且剩余不足 1G”这个阈值可以在脚本里通过参数调整比如核心业务表空间改为 2G。把这条 SQL 放到 cron 里每天早上八点跑一次输出追加到巡检日志长期记录后自然能看到表空间增长曲线比告警阈值更早发现问题。4.2 变更后的启动检查清单从参数到 redo 的核对顺序挂载路径变更、迁移数据文件、调整磁盘布局之后数据库起不来是最常见的变更事故。启动是有顺序的先读参数文件再读控制文件再找 redo 日志最后打开数据文件。检查清单也要按这个顺序写否则在一个环节反复折腾也找不到根因。#!/bin/bash # 变更完成后、正式启动前的参数核对脚本 # 用法: ./check_start.sh ORCL export ORACLE_SID$1 PARAMSdb_name control_files log_archive_dest_1 db_recovery_file_dest for p in $PARAMS; do echo $p echo show parameter $p | sqlplus -s / as sysdba | grep -v ^$ done这个脚本做的事很朴素循环打印关键参数。检查顺序设计成 db_name 在最前是因为数据库名都对不上时后面所有路径检查都没有意义control_files 次之对应挂载路径变更后起不来的案例归档参数再往后因为它们只影响归档模式下的启动与备份不影响实例拉起。执行前确认 ORACLE_SID 环境变量正确执行后人工比对每个路径在新挂载点上是否真实存在。脚本只负责“把参数亮出来”真正的判断还是由人来下这也是它在生产环境里被广泛接受的原因——不做任何自动修改只减少漏看。4.3 轻量脚本与自动化运维平台的边界案例积累到一定程度一定会遇到一个选择题继续写脚本还是上自动化运维平台。这里的边界没有统一答案但有一个经验判断标准脚本方案适合库少、变更少、没有审计要求的团队一旦出现多人协作、审批流程、集中管控的需求脚本就会陷入“每个人都在自己机器上维护一份”的混乱。维度轻量脚本方案自动化运维平台覆盖库数量十套以内够用几十套甚至上百套权限控制依赖操作系统权限支持角色、审批与审计变更追溯靠日志文件平台自动留痕落地成本低当天能跑高需要选型和部署桌面运维助手这类工具能解决主机侧的问题比如批量执行命令、资产盘点但 Oracle 侧的巡检还是需要 SYS 视角的 SQL自动化运维工具对比下来强在流程编排和告警收敛弱在数据库内部指标的理解。所以正确的路径是先把手上的 SQL 和检查清单沉淀成脚本跑上一两个月确认有效再评估要不要接入平台。一上来就追求大而全的工具往往会卡在对数据库理解不足这一步。5. Oracle 运维案例避坑五个容易翻车的现场案例讲得再多最后还是要落到“别再踩坑”。这一章把一线环境里反复出现的五个现场拎出来每条都按“现象—原因—解决”写清楚。这些内容正好也是案例 PPT 里最值得单独成页的部分标题写清故障正文只写排障经过结论只写预防动作。5.1 归档满了直接物理删除实例反而 hang 住现象某客户环境归档目录告警值班同事直接进服务器 rm 掉一批 .arc 文件磁盘空间确实释放了但数据库实例随后 hang 住业务彻底中断。原因物理删除不会同步控制文件里的归档记录rman 和恢复流程会认为归档仍然存在更危险的是删除动作可能波及正在写入的归档或尚未完成备份的日志破坏 redo 链的完整性。解决删除归档必须走 rman删除前先 ALTER SYSTEM SWITCH LOGFILE 切一次日志把当前 redo 与归档切干净再用 DELETE ARCHIVELOG 清理。物理 rm 不是完全不能用但要先停归档再删并且删完要同步处理控制文件记录这个操作只在极端情况下由有经验的 DBA 执行。5.2 修改挂载路径后起不来只改系统没改数据库现象模拟项目 X 里把数据盘从 /u01 改挂到 /u02重启数据库报 ORA-00210 / ORA-00205看起来像控制文件丢失。原因spfile 里的 control_files 参数、数据文件路径、redo 路径还是旧挂载点操作系统路径变了数据库参数不会跟着变。日志里报“找不到控制文件”实际是路径失效而不是文件丢了。解决先 SHOW PARAMETER control_files 核对再用 startup nomount 起空实例确认参数可用若控制文件完好则 ALTER SYSTEM SET control_files 改到新路径后重启若控制文件真的损坏才在 nomount 状态下重建控制文件。空实例启动不是玄学它是恢复流程的标准动作专门用来绕过控制文件做参数层面的修正。5.3 扩容数据文件贪大备份体积一夜翻倍现象表空间告警后 DBA 加了一个 32G 的数据文件业务恢复了但第二天 rman 备份时间翻倍备份存储迅速吃紧。原因一次性分配大块空间数据文件在控制文件里登记为已分配全部空间rman 备份按已分配空间计算即使实际数据只有几百 MB 也按大文件处理。解决新增数据文件用初始小空间加 AUTOEXTEND 自扩展例如 SIZE 8G AUTOEXTEND ON NEXT 1G MAXSIZE 32G既有大文件如果没有实际数据占满不要轻易扩大先评估使用率再动手。备份策略也要配套定期清理过期备份不要让备份保留策略和磁盘扩容互相打架。5.4 监听日志无限增长根分区被悄悄占满现象某天服务器根分区使用率 100%排查后发现 listener.log 已经有几十 GBOracle 监听器还在持续写入。原因监听日志默认不轮转长期运行会无限增长占满分区后影响的不只是监听整个操作系统都可能变慢。解决在操作系统层配置日志轮转或定时切割脚本按天或按大小切割 listener.log同时定期清理保留最近一段时间的日志即可。不同版本对监听日志参数的命名有差异统一用 logrotate 这类系统工具兜底最稳妥再把监听日志大小加入磁盘巡检项避免再次悄悄涨满。5.5 服务器重启后数据库没起来问题出在 oratab现象机房断电重启后应用连不上数据库检查发现 Oracle 实例和监听都没有自动拉起。原因Linux 下 /etc/oratab 中该 SID 条目末尾是 N系统启动脚本不会自动启动数据库Windows 下则多是因为 Oracle 服务启动类型被改成了手动。解决Linux 把 oratab 对应条目末尾改成 Y并确认 dbstart/dbshut 相关脚本有执行权限Windows 用 sc config 把服务改回自动启动然后再手动拉起一次确认。# Linux 确认 oratab 中本 SID 行尾为 Y grep ^orcl /etc/oratab # Windows 将数据库服务设为自动启动服务名按实际 SID 替换 sc config OracleServiceORCL start auto改完配置之后最好在演练环境里做一次“停机再重启”验证确认实例、监听、服务三层都能自动起来而不是等到下次断电才暴露问题。6. 把 PPT 案例转成团队能用的知识库条目案例 PPT 做完不是终点能用起来才是终点。我的习惯是每页案例最终都转成一个四段式的知识库条目事件时间线、根因分析、恢复步骤、预防清单。时间线让后来者看懂过程根因让人知道为什么恢复步骤要写成可执行的命令预防清单则对应一条巡检或检查规则。下面是一个归档清理案例的条目骨架字段内容要求对读者价值事件时间线精确到分钟记录每条命令的执行时机能按顺序复现根因分析说明是哪一层链路断了看懂为什么恢复步骤命令带参数说明路径要参数化能直接执行预防清单对应巡检项或配置项能防复发恢复步骤里最容易被忽视的是“路径写死”。案例里如果写的是当时的绝对路径换了环境就完全不可用。我一般会把步骤参数化比如把归档清理写成一个带参数的脚本每次执行只需改 SID 和保留天数#!/bin/bash # usage: cleanup_arch.sh ORCL 7 export ORACLE_SID$1 rman target / EOF DELETE ARCHIVELOG ALL COMPLETED BEFORE SYSDATE-$2; EOF参数化之后案例才能脱离“当时那台机器”被复用。A同学当年在正式环境里照着案例排查时发现命令里写死的是旧机房路径白白多花了二十分钟从那以后我给自己定了个规矩一份案例归档进知识库之前必须在模拟项目 X 里照着完整跑一遍能复现、能恢复才允许写进去。希望帮到你。本文还有配套的精品资源点击获取