
简介面向数据库运维与系统工程师这份PDF指南完整呈现了在RHEL 7.6上部署Oracle 19C、ASM与DataGuard高可用数据库的详细过程。开篇列出CPU、内存、存储等硬件要求以及Oracle软件与GI安装包版本选择随后围绕主备节点文件系统、安装目录规划、网络地址配置、系统依赖包检查等前置项展开并说明ORACLE_BASE、ORACLE_HOME等目录需要提前创建否则安装时无法检测。核心部分按GI安装、Oracle数据库安装、ASM磁盘组配置、DataGuard主从复制链路建立依次讲解包括节点规划、归档日志传输与备库恢复配置还特别强调network文件权限调整等易错细节。资源为单文件PDF大小4.68MB目前已有703人学习适合需要快速形成项目落地方案的数据库管理员参考。对于想在生产或实验环境快速落地的运维人员这份指南能显著减少排查时间提供清晰可执行的操作路径。1. RHEL 7.6 装 Oracle 19c ASM Data Guard照着就能落地的那份安装指南在 RHEL 7.6 上装 Oracle 19c再配上 ASM 和 Data Guard很多人第一步就卡在不知道先装什么后装什么。这套安装指南给的是一条完整链路先在两个节点上把操作系统基础打牢再装 Grid Infrastructure 把 ASM 磁盘组立起来接着装数据库软件建库最后在主备库之间拉起 Data Guard 同步。我按这份文档在 4 核 20G 内存的机器上完整走了一遍主库 node2、物理备库 node2dg 一次跑通最大的感受是它对“目录要先建全、包要先装齐、udev 规则要先落”这几处盯得特别紧。适合第一次在 Linux 上装 19c 的新手照着敲也适合熟手用来对照检查自己的安装习惯。2. 部署规划与系统准备先核验硬件、再补齐依赖、最后建用户目录2.1 硬件、版本与文件系统验收先看资源再动手开始装 Oracle 之前先把机器的家底摸清楚。Oracle 19c 官方的硬件门槛其实不高内存建议不小于 2GB显示分辨率 1024x768 以上swap 按内存大小来配。但生产或测试环境一般都会给得更多文档里这套实验环境用的是 4 核 CPU、20G 内存、200G 存储属于比较典型的入门配置。装机前我会先跑一遍下面这组命令grep MemTotal /proc/meminfo free -g swapon -s cat /etc/redhat-release uname -r df -h先用 grep MemTotal 看物理内存是不是 20G再用 free -g 和 swapon -s 确认 swap 和物理内存的比例。这里的经验是swap 并不是越大越好官方建议是物理内存在 2.5G 到 16G 之间时swap 和内存保持一致内存超过 16G 时 swap 固定 16G 就够了。文档里的机器配了 20G swap属于多点无碍但如果你的机器内存更大别把 swap 配成和内存一样大白白浪费磁盘空间。RHEL 版本要认准 7.6也就是 /etc/redhat-release 里显示 Maipo。内核版本 3.10.0-957 就是对应 7.6 的内核。Oracle 19c 对 7.6 的认证比较成熟实验环境用这个组合最稳。df -h 主要看 / 和 /app 两个挂载点根分区 20G/app 一个节点 45G、另一个 40G安装软件和数据库文件都放 /app 下空间宽裕。官方建议 ORACLE_BASE 至少留 7.5GB这套规划里装完系统包、解压完软件后仍然充足没有问题。2.2 软件包核对与安装不是所有依赖都能在镜像里找齐Oracle 19c 在 RHEL 7.6 上的依赖包有一长串文档里把检查命令直接列了出来。我习惯把所有依赖放进一条 rpm -q 命令里批量查缺哪个一眼就能看出来rpm -q --qf %{NAME}-%{VERSION}-%{RELEASE} (%{ARCH})\n bc \ binutils compat-libcap1 compat-libstdc-33 glibc glibc-devel \ ksh libaio libaio-devel libX11 libXau libXi libXtst \ libXrender-devel libXrender libgcc libstdc libstdc-devel \ libxcb make nfs-utils net-tools python python-configshell \ python-rtslib python-six smartmontools sysstat targetcli命令输出会列出每个包的版本没有任何一行输出的包就是缺的。缺了的直接用 yum 装yum install bc binutils compat-libcap1 compat-libstdc-33 glibc \ glibc-devel ksh libaio libaio-devel libX11 libXau libXi libXtst \ libXrender-devel libXrender libgcc libstdc libstdc-devel \ libxcb make nfs-utils net-tools python python-configshell \ python-rtslib python-six smartmontools sysstat targetcli这里有个坑必须提前说RHEL 7.6 的安装镜像里没有 compat-libstdc 这个包你执行 yum install compat-libstdc-33 大概率会提示找不到软件包。文档里的做法是先准备好两个 rpm 手动装compat-libstdc-33-3.2.3-72.el7.i686.rpm 和 compat-libstdc-33-3.2.3-72.el7.x86_64.rpm。我一般会把这两个包提前下载到 /root 下等 yum 装完其余依赖后单独 rpm -ivh 装上去安装顺序不影响结果但一定要在跑图形安装之前装完否则 OUI 的前置校验阶段会一直亮着红叉拦住你。2.3 用户组、目录规划与网络配置先把完整路径建出来这是整套安装里最容易被跳过的部分也是翻车率最高的部分。Oracle 19c 的 ASM 环境需要两个系统用户grid 管 Grid Infrastructure 和 ASMoracle 管数据库软件。用户组要建 10 个GID 从 54321 开始依次排这个范围是官方推荐可以避免和系统中其他用户的 ID 冲突。文档里的建组建用户命令是一整串核心结构是/usr/sbin/groupadd -g 54321 asmadmin /usr/sbin/groupadd -g 54322 asmdba /usr/sbin/groupadd -g 54323 asmoper /usr/sbin/groupadd -g 54324 dba /usr/sbin/groupadd -g 54325 oper /usr/sbin/groupadd -g 54326 oinstall /usr/sbin/useradd -u 54321 -g oinstall -G dba,asmdba,backupdba,dgdba,kmdba,racdba,oper oracle /usr/sbin/useradd -u 54322 -g oinstall -G asmadmin,asmdba,asmoper,dba grid注意两个关键点oracle 用户必须属于 dba 和 asmdba因为它要读写 ASM 磁盘上的数据库文件grid 用户必须属于 asmadmin因为它要管理磁盘组。用户建完之后下一步是创建安装目录文档给了一张清晰的规划表用途路径grid 的 ORACLE_BASE/app/gridGI 的 ORACLE_HOME/app/product/19.2.0/crsoracle 的 ORACLE_BASE/app/oracle数据库的 ORACLE_HOME/app/oracle/product/19.2.0/dbhome_1集中 Inventory/app/oraInventory把命令合起来就是mkdir -p /app/grid mkdir -p /app/product/19.2.0/crs mkdir -p /app/oracle/product/19.2.0/dbhome_1 mkdir -p /app/oraInventory很多人会忽略这一步直接去跑安装程序结果 OUI 里选 ORACLE_HOME 路径时下一步按钮始终点不了。原因不是权限问题而是这个全路径根本不存在。官方要求 ORACLE_HOME 目录必须预先建好软件会装在 gridSetup.sh 所在路径所以目录不建安装程序直接判失败。最后别忘了网络上的小调整文档里要求 chmod 644 /etc/sysconfig/network 并在文件末尾追加 NOZEROCONFyes作用是禁止系统自动配置空路由避免集群通信时出现多余路由干扰。注意两个节点的 /etc/sysconfig/network 都要改只改主库不改备库后面 Data Guard 传输归档日志时可能会出现跨节点路由混乱的问题。3. 内核参数与系统服务调整shmmax、limits 与 chrony 的取舍3.1 sysctl.conf 参数逐条解读先把共享内存和信号量算明白Oracle 对 Linux 内核参数的依赖非常大尤其是共享内存段大小和信号量。文档给的 /etc/sysctl.conf 是一份可以直接抄的作业fs.aio-max-nr 1048576 fs.file-max 6815744 kernel.shmall 4294967296 kernel.shmmax 12640516096 kernel.shmmni 4096 kernel.sem 250 32000 100 128 net.ipv4.ip_local_port_range 9000 65500 net.core.rmem_default 262144 net.core.rmem_max 4194304 net.core.wmem_default 262144 net.core.wmem_max 1048576逐条看fs.aio-max-nr 是异步 IO 请求的上限Oracle 的 IO 路径重度依赖 aio给到 1048576 足够。fs.file-max 是系统级文件句柄上限Oracle 的进程多、文件句柄消耗大6815744 是官方建议。kernel.shmall 和 kernel.shmmax 这一对最让人迷糊shmmax 是单个共享内存段的最大字节数shmall 是共享内存总页数。文档里 shmmax12640516096 约等于 11.7GB接近物理内存 20G 的一半这个是按照 Oracle 对 SGA 的常规建议配的。很多人在这个参数上翻车其实是把单位搞混了。shmall 的单位是页默认 4KBshmmax 的单位是字节。一个常用的核对公式是shmall 乘以页大小必须大于或等于 shmmax。文档里 shmall 给到 4294967296换算过来是 16TB 的地址空间完全覆盖 shmmax没有问题。如果你拿不准自己的配置把 sysctl -p 执行后再用 ipcs -l 看系统实际的共享内存上限是不是和配置文件一致。kernel.sem 的四个值分别对应每个信号量集的最大信号量数、系统范围最大信号量数、每个信号量操作的最大操作数、系统范围最大信号量集数。Oracle 文档建议就是 250 32000 100 128这四个值不用自己发挥照抄即可。net.ipv4.ip_local_port_range 从 9000 开始是给 Oracle 和 Data Guard 的通信预留更多可用端口特别是主备库之间的归档日志传输端口池太小会直接导致连接失败。rmem 和 wmem 是 TCP 收发缓冲区默认值和最大值按文档给的值配好一般不用再动。3.2 用户 Shell 限制与 PAMnofile、nproc、memlock 一个不能少内核参数管的是系统层用户进程的资源限制则靠 /etc/security/limits.conf。这份文档给 grid 和 oracle 两个用户都配了同样的限制grid soft nproc 2047 grid hard nproc 16384 grid soft nofile 1024 grid hard nofile 65536 grid soft stack 10240 grid hard stack 32768 grid soft memlock 3145728 grid hard memlock 3145728 oracle soft nproc 2047 oracle hard nproc 16384 oracle soft nofile 1024 oracle hard nofile 65536 oracle soft stack 10240 oracle hard stack 32768 oracle soft memlock 3145728 oracle hard memlock 3145728nproc 是进程数上限nofile 是打开文件数上限stack 是栈大小memlock 是内存锁定上限。这里最值得说的是 memlock单位是 KB3145728 KB 就是 3GB。它的作用是允许 Oracle 进程把共享内存段锁定在物理内存里不被交换到 swap。如果这个值设得太小数据库实例启动时可能会报“无法锁定内存”的经典错误设得太大又会白白占用物理内存。3GB 对中型实验库来说合理如果以后要上生产建议按 SGA 大小适当上调。limits.conf 改完后还要在 /etc/pam.d/login 里加上一行session required pam_limits.so这一步非常容易被漏掉。加与不加的区别在于不加这行通过 SSH 或图形登录创建的会话不会加载 limits.conf 里的限制前脚改完 ulimit -n 还是 1024。加上后重新登录一次再用 ulimit -n、ulimit -l、ulimit -u 验证确认结果分别是 65536、3145728、16384 就对了。3.3 时间同步与服务清理关掉 chrony让 ctss 接管在集群类架构里时间同步是个老生常谈的话题。Oracle 的 Grid Infrastructure 自带一个集群时间同步服务 ctss如果你不配置外部时间源ctss 会自动接管并在集群节点之间校准时间。文档里的做法是在实验环境里把 chrony 关掉让 ctss 自己工作systemctl list-unit-files | grep chronyd systemctl stop chronyd systemctl disable chronyd mv /etc/chrony.conf /etc/chrony.conf_bak先停服务再禁用开机自启最后把配置文件备份改名这样后面想恢复还有后悔药可吃。生产环境如果已经有企业级 NTP 或 chrony 服务器可以保留外部时间源不需要强制关闭但测试环境没有外部时间服务器的话留着 chrony 反而可能和 ctss 抢时间同步的控制权造成时间漂移。同样要处理的是 avahi-daemon 服务。这个服务负责多播 DNS 和局域网设备发现在 Oracle 集群环境里属于明确的禁用对象因为它会周期性发送组播报文干扰集群节点之间的私网通信。操作方式跟 chrony 一样systemctl stop 加 disable 两步走完。这两个服务检查完之后基础系统层面就干净了可以进入共享存储和 ASM 的环节。4. ASM 磁盘绑定与 Grid 安装udev 规则和磁盘组的正确姿势4.1 共享存储识别与 udev 绑定用 scsi_id 固定设备名ASM 要用的磁盘不是普通文件系统分区而是共享存储上划出的裸盘。在虚拟化环境里通常能看到 sdc、sdd、sde、sdf 四块盘。直接把这些设备名写进配置是不靠谱的因为每次重启后内核枚举顺序可能变化sdc 可能变成 sdd。文档里的做法是用 udev 规则把每个磁盘的 WWID 绑成固定的 /dev/asmdiskXX 设备这是 Linux 环境下给 ASM 喂盘的通用做法。第一步先拿到每块盘的唯一标识/usr/lib/udev/scsi_id -g -u /dev/sdc /usr/lib/udev/scsi_id -g -u /dev/sdd /usr/lib/udev/scsi_id -g -u /dev/sde /usr/lib/udev/scsi_id -g -u /dev/sdf每块盘会输出一串类似 36000c29... 的字符串这是磁盘的 SCSI WWID。接下来把这四组 ID 写进 /etc/udev/rules.d/99-my-asmdevices.rules。RHEL 7 的规则文件写法和 6 不完全一样文档里这份是直接在规则里调用 mknod 建设备文件KERNELsd*[!0-9], ENV{DEVTYPE}disk, SUBSYSTEMblock, \ PROGRAM/usr/lib/udev/scsi_id -g -u -d $devnode, \ RESULT36000c291ca220c52c813c595ffdf14f4, \ RUN/bin/sh -c mknod /dev/asmdisk01 b $major $minor; chown grid:asmadmin /dev/asmdisk01; chmod 0660 /dev/asmdisk01规则里有三个关键点。KERNELsd*[!0-9] 表示匹配整块盘而不匹配 sdX1 这种分区因为 ASM 要的是整盘。RESULT 的值必须和 scsi_id 输出完全一致多一个空格少一个字符都不行。RUN 里先用 mknod 按主次设备号创建设备文件再改成 grid:asmadmin 属主和 0660 权限这样 grid 用户才能通过 ASM 实例读写这些盘。规则文件写完后执行一次触发让规则立即生效/sbin/udevadm trigger --typedevices --actionchange验证方式很简单ls -l /dev/asmdisk* 看是否存在四个设备并且属主是 grid:asmadmin。这里我吃过一次亏当时 scsi_id 输出是 36000c29 开头的一串我从文本复制进规则文件时多了个不可见字符结果磁盘在安装界面死活不出现。后来排查了十分钟才发现是 RESULT 串不一致所以强烈建议每一条规则的 RESULT 手动复制、不要凭印象手敲。4.2 Grid Infrastructure 安装先设好环境变量再跑 gridSetupGI 安装前grid 用户的环境变量必须就位。文档里给出的核心配置是export ORACLE_SIDASM export ORACLE_BASE/app/grid export ORACLE_HOME/app/product/19.2.0/crs export PATH$PATH:$ORACLE_HOME/bin这里要注意 ORACLE_SID 必须写成 ASM不是 ASM1 也不是别的单实例 ASM 的默认实例名就是 ASM。环境变量配置完成后解压 GI 软件包unzip V981627-01.zip -d /app/product/19.2.0/crs然后进入解压目录执行 gridSetup.sh/app/product/19.2.0/crs/gridSetup.sh这里大概率会弹出图形界面如果没有图形环境需要靠 X 转发或 VNC。安装过程中有几步选择非常关键。第一是安装类型虽然是单实例数据库但这里不选“仅安装 Oracle Grid Infrastructure 软件”而是选 standalone server英文界面叫 Standalone server中文界面显示独立服务器。第二是配置 ASM 磁盘组这一步进入 Change Discovery Path把 /dev/asmdisk* 的路径填进去让安装程序扫描出四块盘。第三是磁盘组冗余模式文档里选的是 Normal。4.3 磁盘组冗余策略Normal 意味着要多烧一块盘的容量ASM 的冗余模式直接影响数据安全性和存储利用率。External 是外部冗余ASM 不做镜像靠存储阵列自身的 RAID 兜底最少一块盘就能建组。Normal 是 ASM 自己做两路镜像数据写一份、再镜像一份至少需要两块盘文档给了四块盘所以选 Normal 是合理的。冗余模式在磁盘组创建后不能改不像参数可以随便调所以这里得一次选对。我一般的原则是没有外部 RAID 的测试环境选 Normal能模拟生产环境的行为有存储阵列兜底的选 External能省一半空间。选完冗余后设置管理密码文档里统一用 oracle。安装完成之后用 crsctl 和 asmcmd 检查状态是必不可少的crsctl stat res -t asmcmd lsdgcrsctl stat res -t 能看到集群资源是否 onlineasmcmd lsdg 能看到 DATA 磁盘组的总大小、可用大小和冗余类型。这里如果看到磁盘组状态是 MOUNTED就说明 ASM 实例和磁盘组都正常Grid Infrastructure 这层已经落地。到这一步ASM 基础设施就绪接下来才轮到数据库软件安装。注意ASM 磁盘组的名字建议直接用 DATA不要起太花哨的名字。后面数据库文件的路径、RMAN 备份路径都依赖这个磁盘组名起复杂了只会让自己在写参数时更容易出错。5. 常见问题排查安装与配置阶段必踩的 5 个坑装 Oracle 19c 环境一次过的概率其实不高。我按这套文档在主备两台机器上先后复现了两遍第一遍就踩了两个坑第二遍才完全跑顺。下面这五个坑是最常见的每一条按现象、原因、解决三段式写看的时候可以对号入座。5.1 缺少 compat-libstdc-33 导致安装前检查不合格现象oracle 用户跑安装程序时前置条件检查弹出红叉提示缺少 compat-libstdc-33执行 yum install compat-libstdc-33 却提示没有可用软件包。原因RHEL 7.6 的 DVD 镜像里没有包含 compat-libstdc-33这个包不在默认源里离线环境根本装不上。解决提前准备好 compat-libstdc-33-3.2.3-72.el7.i686.rpm 和 compat-libstdc-33-3.2.3-72.el7.x86_64.rpm在跑安装程序之前先用 rpm -ivh 手动装上去两个架构的包都要装。装完后再执行一次 rpm -q compat-libstdc-33 确认红色报错就会消失。5.2 OUI 提示 ORACLE_HOME 路径不存在下一步按钮置灰现象在图形界面里指定 Oracle Home 路径后下一步按钮始终不可点击界面提示路径不存在或无法验证。原因安装程序要求 ORACLE_HOME 的完整路径提前创建但很多人跳过了 mkdir 直接进安装界面所以路径校验不通过。解决回到 shell 里按规划的路径执行 mkdir -p /app/product/19.2.0/crs 和 mkdir -p /app/oracle/product/19.2.0/dbhome_1然后再回到 OUI 点击重新验证。这个坑在 GI 和 DB 两个安装过程中各会遇到一次提前把目录建全是最廉价的准备动作。5.3 udev 绑定后 ASM 磁盘在发现路径里看不到现象gridSetup 的磁盘组创建页面点击 Change Discovery Path 后候选磁盘列表为空或者只有部分磁盘出现。原因最常见的有三种一是规则文件里的 RESULT 和实际 scsi_id 输出不一致二是规则写完没有执行 udevadm trigger新规则没有生效三是 /dev/asmdisk* 的属主或权限不对grid 进程没有访问权限。解决先执行 /usr/lib/udev/scsi_id -g -u /dev/sdc 重新核对 RESULT 字符串再确认规则文件里引用的设备名没有多打字最后执行 /sbin/udevadm trigger --typedevices --actionchange 并 ls -l /dev/asmdisk* 检查属主。属主必须是 grid:asmadmin权限必须是 660如果不满足回看规则里的 chown 和 chmod 是否被正确执行。5.4 root.sh 执行到一半报 ohasd 启动失败现象GI 安装到最后要求用 root 执行 /app/product/19.2.0/crs/root.sh脚本执行完但最后几行报 ohasd failed to start随后 crsctl check has 也返回失败。原因这属于安装阶段最经典的组合拳问题常见诱因有三个残留的 Oracle 进程没清干净、kernel.sem 参数没生效、/etc/oracle 目录权限不对导致 ohasd 无法写状态文件。解决先看 /var/log/messages 里有没有和 ohasd 相关的直接报错再执行 ps -ef | grep d.bin 看有没有残留进程有就 kill 掉。然后确认 sysctl -p 已经执行过kernel.sem 输出是 250 32000 100 128 四个值。最后确保 /etc/oracle 目录存在且属主是 root:oinstall权限 775。这三个点逐个排除后再重新执行 root.sh基本都能过。5.5 Data Guard 备库停在 mount 状态MRP0 进程不出现现象备库数据库用 alter database open 打开后能读到控制文件但 v$managed_standby 里看不到 MRP0 进程主库切归档日志后备库也不应用。原因备库没有启动日志应用或者备库实例没有处于 mount 状态。Data Guard 的物理备库不能像普通库一样 open必须以 mount 方式运行然后用 recover managed standby database 启动日志应用。解决备库执行 shutdown immediate 后以 mount 方式启动SQL STARTUP MOUNT; SQL ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;再次查询 v$managed_standby看到 MRP0 进程处于 WAIT_FOR_LOG 状态就说明应用已启动。如果启动报错还要检查备库是否创建了 standby redo log没有的话先建好再启动 MRP0。这个坑最容易让人误判成网络问题实际上绝大多数情况是备库角色还没进入日志应用模式。6. Data Guard 配置与验证从建库到角色切换一气呵成6.1 数据库软件安装与 DBCA 建库要点GI 落地后数据库软件的安装流程相对轻松。oracle 用户环境下解压 V981623-01.zip执行 runInstallerORACLE_HOME 指向 /app/oracle/product/19.2.0/dbhome_1一路下一步到安装完成。建库用 DBCA字符集按文档建议选 AL32UTF8别再用 ZHS16GBK19c 里 UTF8 是更省心的选择。建库时把主备两个节点的监听都配上后续 Data Guard 传输归档日志依赖的是网络服务名连接。6.2 主备参数设置与归档链路配置主库和备库的 db_unique_name 不能一样否则 Data Guard 无法区分角色。主库 node2 的 db_unique_name 保持 node2备库设成 node2dg然后主库执行ALTER DATABASE FORCE LOGGING; ALTER SYSTEM SET LOG_ARCHIVE_CONFIGDG_CONFIG(node2,node2dg) SCOPEBOTH; ALTER SYSTEM SET LOG_ARCHIVE_DEST_1LOCATION/app/archive VALID_FOR(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAMEnode2 SCOPEBOTH; ALTER SYSTEM SET LOG_ARCHIVE_DEST_2SERVICEnode2dg LGWR ASYNC VALID_FOR(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAMEnode2dg SCOPEBOTH;LOCATION 指定本地归档目录SERVICE 指定备库的网络服务名LGWR ASYNC 表示日志写进程异步传输这是 19c 里兼顾性能和安全的推荐方式生产环境习惯用 SYNC 模式传输到备库但实验环境 ASYNC 就够用。备库侧用 RMAN duplicate 从主库把数据文件复制过来再为本库建好 standby redo log日志组数和主库在线日志组数保持一致。6.3 验证同步并做一次角色切换测试配置完不等于能用了我每次都会做一次切日志验证这是判断 Data Guard 是否真正在工作的最直接手段SQL ALTER SYSTEM SWITCH LOGFILE; SQL SELECT DEST_ID, STATUS, ERROR FROM V$ARCHIVE_DEST_STATUS; SQL SELECT PROCESS, STATUS, THREAD# FROM V$MANAGED_STANDBY;主库切一次日志备库立刻收到并应用v$managed_standby 里看到 MRP0 进程处于 WAIT_FOR_LOG说明同步链路已经通了。想要更严谨可以执行一次 switchover 把主备角色对调再切回来验证角色切换能力。这套安装指南把 GI、ASM、数据库和 Data Guard 的命令、参数和图形界面操作串成了一条完整链路下载后对照着截图一步步复现比自己东拼西凑查资料省太多时间。我从那以后每次搭完 Oracle 19c 主备环境都会强制走一遍日志切换和 MRP0 进程检查确认这一层真的健康再往上叠希望帮到你。本文还有配套的精品资源点击获取