简介《Oracle 19c RAC on Linux 7.6安装手册》面向在Red Hat Enterprise Linux 7.6上部署Oracle 19c RAC的数据库管理员与运维工程师围绕集群安装、GNS配置SCAN及Flex ASM等关键环节提供系统化参考。手册从OS环境检查入手涵盖关闭THP并开启Hugepages、安装RHEL 7与补充软件包、内核参数配置、CVU检查、固定网络及GNS固定网络配置、操作系统杂项与时钟同步等模块并梳理从12.2起Standalone Cluster与Domain Service Cluster两种集群模式的差异及版本变化附有配置问题解决与分析思路便于读者按目录定位排错。包内共1个docx文档压缩包约160KB轻量便于查阅。已有719人学习适合需要完成19c RAC落地、理解GNS与SCAN配置细节的中高级DBA参考。1. 一台机器上第三次装 19c RAC卡在 GNS 委派去年帮人排查一套两节点集群19c RAC Linux 7.6 安装手册翻来覆去看了三遍gridSetup.sh 每次跑到网络页就停——SCAN 域名解析不出来GNS 服务明明起来了。问题不在手册写错了而在于手册通常只写“怎么做”不写“为什么这一步必须这么摆”。这份 19c RAC on Linux 7.6 安装手册的价值在于把从 OS 预检、THP 与 HugePages、内核参数、依赖包、CVU 预检、网络与 GNS、ASM UDEV 到 gridSetup.sh 与 dbca 的整条链路串了起来尤其对 Flex Cluster 下 Standalone Cluster 与 Domain Services Cluster 两种模式的差别有明确交代。适合第一次上 19c RAC 的 DBA、从 11g/12c 往 19c 迁移的运维以及要给内部测试环境搭一套两节点集群的工程师。下面按我实际复现的顺序拆参数和坑都落到命令上。2. OS 环境预检swap、/dev/shm 与 HugePages 的四个硬阈值装集群最容易被跳过的是预检最容易在安装到 70% 时炸的也是预检。手册里列的那张检查表看着平淡实际每一项都对应一个后续阶段的失败模式内存不够会在 ASM 实例启动时 OOM/dev/shm 太小会让 dbca 在最后一步挂掉swap 与 HugePages 的账算错会让 GI 启动时报内存分配失败。这一章先把预检做成可执行的判定再把 THP 和 HugePages 这对“玄学组合”拆开。2.1 五项预检与判定标准手册要求的最低配置是 RAM 至少 8G、/tmp 至少 1G、运行级别 3 或 5、内核版本满足 19c 的兼容列表、grid 与 oracle 各留出足够软件空间。这些数字不能只看“满足”还要看“留余量”。我一般在测试环境按 16G 内存、100G /u01 起步因为 19c 的 GI 家目录加上 ASM 元数据、GIMR如果启用、OCR 与 voting disk实际占用比预估高不少。检查项命令判定标准常见后果物理内存grep MemTotal /proc/meminfo≥ 8G建议 16G 起ASM 实例启动失败Swapgrep SwapTotal /proc/meminfo4~16G 等于 RAM16G 取 16G大页启用后需扣减/tmpdu -sh /tmp≥ 1G 可用安装器解压失败/dev/shmdf -h /dev/shm挂载为 tmpfs权限 1777dbca 建库中断软件空间df -h /u01grid ≥ 12Goracle ≥ 10G安装到一半空间不足运行级别runlevel3 或 5图形安装器无法启动内核版本uname -mr见手册兼容列表GI 拒绝安装一次性把这些命令跑完比在安装器里被逐条拦下来舒服得多# 一次性把预检项打出来方便贴进变更单 echo memory ; grep MemTotal /proc/meminfo echo swap ; grep SwapTotal /proc/meminfo echo tmp ; df -h /tmp echo shm ; df -h /dev/shm echo u01 ; df -h /u01 echo release ; cat /etc/redhat-release echo kernel ; uname -mr echo runlevel ; runlevel这段脚本没有逻辑分支价值在于“一次采集、一次判断”。参数上唯一需要留意的是 swap 的计算规则4G 到 16G 之间取与 RAM 等值超过 16G 一律按 16G 规划如果启用了 HugePagesswap 的规划值要减去分给大页的那部分内存否则预检脚本和实际可用内存对不上后面 CVU 会报出看似莫名其妙的 PRVF 类错误。提示/dev/shm 的挂载类型必须是 tmpfs权限 1777。有些加固基线会把它改成 0755 或缩小到 1G这在 19c 上会直接让 dbca 在创建 PDB 阶段失败。2.2 禁用 THP 的两个落点enabled 与 defrag透明大页面THP是 RAC 上的老问题。手册里先看两个文件/sys/kernel/mm/transparent_hugepage/enabled和/sys/kernel/mm/transparent_hugepage/defrag方括号落在always就说明开着。只改 enabled 不改 defrag是血泪经验里最常见的一种“看起来关掉了”。defrag 保持 always 时内核仍会做内存碎片整理GI 的 SGA 分配延迟会抖动严重时集群心跳超时。# 先确认现状方括号在哪一项就是当前值 cat /sys/kernel/mm/transparent_hugepage/enabled cat /sys/kernel/mm/transparent_hugepage/defrag运行期临时改只对当前启动有效重启即失效所以正确的落点在内核命令行。把transparent_hugepagenever追加到GRUB_CMDLINE_LINUX然后按 BIOS 或 UEFI 选择不同的 grub.cfg 路径重建# 备份后追加内核参数避免改坏原行 cp /etc/default/grub /etc/default/grub.bak.$(date %F) sed -i s/^GRUB_CMDLINE_LINUX/GRUB_CMDLINE_LINUXtransparent_hugepagenever / /etc/default/grub # BIOS 机器 grub2-mkconfig -o /boot/grub2/grub.cfg # UEFI 机器改用这条 # grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg reboot cat /proc/cmdline # 确认参数已经进了启动命令行/proc/cmdline里出现该参数只说明内核收到了还要回读两个 sysfs 文件确认never生效。这一步在三节点集群上必须每台都做并且要在安装 GI 之前完成——GI 安装后再改需要重启节点滚动重启的窗口成本比一次规划高得多。注意sed 只匹配以GRUB_CMDLINE_LINUX开头的行。如果机器上有多行同名变量例如同时存在GRUB_CMDLINE_LINUX_DEFAULT不要用全局替换逐行看清再改。2.3 HugePages 与 memlock 的联动账HugePages 的账要分两种集群模式算。Standalone Cluster 在 19c 里 GIMR 是可选项不配 GIMR 就只算数据库 SGADomain Services Cluster 需要 GIMRGIMR 自身会吃掉大约 1G 的 SGA这部分必须计入大页总数。算法是SGA 总量除以单页大小x86_64 默认 2M向下取整后再加 5%~10% 的余量。以数据库 SGA 16G、启用 GIMR 为例16384M ÷ 2M 8192 页GIMR 1G 折 512 页合计 8704 页留 5% 余量约 9140 页。写成配置是# 大页数量写进 sysctl随系统启动生效 echo vm.nr_hugepages 9140 /etc/sysctl.conf sysctl -p # memlock 按大页总量换算单位 KB9140 * 2048 18718720 cat /etc/security/limits.d/19c-hugepages.conf EOF oracle soft memlock 18718720 oracle hard memlock 18718720 grid soft memlock 18718720 grid hard memlock 18718720 EOF # 确认实际分配到的页数可能小于请求值 grep -i hugepages /proc/meminfo这里有两个参数容易翻车。vm.nr_hugepages是“请求值”内核在内存碎片化时未必能凑够所以/proc/meminfo里的HugePages_Total要回读确认。memlock的单位是 KB 而不是页数写少了会出现“大页分到了但实例起不来”的现象limits.conf里的值必须不小于大页占用的总字节数grid 与 oracle 两个用户都要给。3. 依赖包与内核参数preinstall RPM 与手工配置的分界线到了软件层选择只有两条用 Oracle 提供的 preinstall RPM 一把梭或者全部手工配。两条路都能装成差别在于“谁替你兜底”。preinstall RPM 会建用户、建组、写 sysctl、写 limits、顺手把 numa 关掉省事但改了什么不透明手工配置每一项都能解释但漏一项就要在 CVU 阶段返工。我在生产环境倾向 preinstall 打底再逐项复核测试环境纯手工方便对照。3.1 preinstall RPM 到底改了什么在 RHEL 7.6 或 Oracle Linux 7 上加好仓库后直接装oracle-database-preinstall-19c。它会创建 oracle 用户、oinstall 与 dba 组写好/etc/sysctl.d/下的参数文件配置 hard/soft 资源限制并设置numaoff。装完不要以为完事至少回读三处用户与组是否存在、sysctl -a里的关键项是否符合预期、ulimit -a在 oracle 用户下是否放开。# 安装预配置包RHEL/Oracle Linux 7 通用 yum install -y oracle-database-preinstall-19c # 三处回读确认它到底改成了什么 id oracle sysctl -a | grep -E fs.aio-max-nr|fs.file-max|kernel.sem|kernel.shm su - oracle -c ulimit -a参数上值得关注的是numaoff。这一项在小内存机器上影响不明显在多路多核、NUMA 节点跨度大的机器上会改变内存分配行为如果后续要做绑核或大页本地化需要重新评估。preinstall 装的包不包含 cvuqdisk那个要单独从 Grid 安装介质里取。3.2 手工 sysctl 与 limits.conf 的逐项含义不用 preinstall 就得自己写。手册给了完整的一组值我按用途归类fs.aio-max-nr控制异步 IO 请求上限ASM 高并发时不够会报 IO 错误fs.file-max是系统级文件句柄总量kernel.shmall与kernel.shmmax决定共享内存段的大小shmmax 直接卡住 SGA 上限kernel.sem是信号量四元组对应 semmsl、semmns、semopm、semmni网络那四项是端口范围与 socket 缓冲区。cat /etc/sysctl.d/97-oracledatabase-sysctl.conf EOF fs.aio-max-nr 1048576 fs.file-max 6815744 kernel.shmall 2097152 kernel.shmmax 4294967295 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 EOF sysctl --system sysctl -a | grep -E fs.aio-max-nr|kernel.sem|kernel.shmmaxkernel.shmmax 4294967295是 4G 减 1意味着单段共享内存不能超过 4G如果 SGA 规划大于 4G需要按字节数往上调否则 GI 安装时校验会提示 SGA 超限。net.ipv4.ip_local_port_range从默认的 32768 起改到 9000 起是为了给监听器和 VIP 留出低端口段集群环境下端口冲突排查起来很费时间提前规划省事。用户级限制单独写一个文件不要直接改/etc/security/limits.conf主体方便审计和回滚cat /etc/security/limits.d/19c-oracle.conf EOF oracle soft nproc 16384 oracle hard nproc 16384 oracle soft nofile 65536 oracle hard nofile 65536 oracle soft stack 10240 oracle hard stack 10240 EOF # 用 oracle 身份登录后复核注意 su 与 ssh 登录读到的值可能不同 su - oracle -c ulimit -n; ulimit -u; ulimit -snofile在 RAC 上要格外注意ASM 实例、数据库实例、集群ware 三套进程都在抢文件句柄65536 是起步值。用su -切换看到的限制和通过 ssh 登录看到的可能不一致因为 PAM 的加载顺序不同最终以 ssh 会话里的ulimit为准。3.3 cvuqdisk 与 runcluvfy 的预检闭环CVUCluster Verification Utility是安装前的最后一道闸。cvuqdisk 这个 RPM 不在系统仓库里在 Grid 安装介质的cv/rpm目录下必须每台节点都装并且版本一致。装之前先查有没有旧版有就先删否则会出现“CVU 能跑但读不到磁盘信息”的怪现象。# 旧版先卸载 rpm -qi cvuqdisk rpm -e cvuqdisk # 指定归属组后安装 export CVUQDISK_GRPoinstall rpm -ivh /u01/media/grid/cv/rpm/cvuqdisk-1.0.10-1.rpm # 两节点预检-fixup 表示允许它给出修复建议 /u01/media/grid/runcluvfy.sh stage -pre crsinst -fixup -n node1,node2-n后面的节点名必须和/etc/hosts里解析出来的一致不能用 IP 代替否则 CVU 的互信检查会失败。-fixup只输出建议不自动改看输出时重点盯三类节点间时间偏差、hosts 解析一致性、用户等价性ssh 互信。这三类占了预检失败原因的绝大多数而且都能在装 GI 之前十分钟内解决。3.4 系统杂项I/O 调度、SSH 超时、X11 与时钟这几项散在手冊的“其他配置”里单独看都不起眼合起来决定集群稳不稳。I/O 调度器对 SSD 用none、对机械盘用deadline用 udev 规则固化比手工 echo 可靠SSH 超时限制关系到 GI 安装时的节点间通信默认太长会在断网时挂住X11 Forward 在集群节点上一般关掉减少攻击面时钟同步用 chrony节点间偏差超过阈值集群直接起不来。# 按磁盘类型分别设置调度器重启后依然生效 cat /etc/udev/rules.d/60-iosched.rules EOF ACTIONadd|change, KERNELsd[a-z], ATTR{queue/rotational}0, ATTR{queue/scheduler}none ACTIONadd|change, KERNELsd[a-z], ATTR{queue/rotational}1, ATTR{queue/scheduler}deadline EOF udevadm control --reload-rules udevadm trigger # SSH 保活与关闭 X11 转发改完重启服务 cat /etc/ssh/sshd_config EOF ClientAliveInterval 300 ClientAliveCountMax 3 X11Forwarding no EOF systemctl restart sshd # chrony 指向内网时间源并确认同步状态 sed -i s/^server .*/server 192.168.204.1 iburst/ /etc/chrony.conf systemctl enable --now chronyd chronyc sources -vClientAliveInterval 300配合ClientAliveCountMax 3表示 15 分钟无响应才断比默认的无限等待更可控。chrony 的iburst让首次同步快很多chronyc sources -v输出里前缀^*才代表已选中同步源只看到^?说明还没同步上这时候装 GI 大概率在时钟校验环节被拦。4. 网络与 GNSPublic/VIP/Private/SCAN 的落位与子域委派网络是 19c RAC 安装里最需要提前画图的部分。手册明确了几条约束要么全 IPv4 要么全 IPv6Public、VIP、SCAN VIP 必须在同一子网Public 与 VIP 名称只能用字母数字和连字符不能用下划线Private 最多四个网卡参与 HAIP超出的自动降为冗余且 Private 可以不做 bond集群自己会做高可用。这些约束每一条都对应一个安装器里的红叉。4.1 四类地址的角色与命名约束先把角色分清。Public IP 是节点对外的管理地址固定绑在网卡上Private IP 走心跳和 Cache Fusion最好独立网段VIP 是节点故障时漂移的地址18c 起变成可选项但手册特别注明“要么全配要么全不配”只给部分节点配 VIP 是不支持的SCAN 是客户端连接入口建议三个 IP 轮询GNS 则是把 VIP、Private、SCAN 的分配交给 DNS 动态管理。地址类型数量建议所在网段是否可交给 GNS命名限制Public每节点 1 个业务网段否需固定字母数字与连字符VIP每节点 1 个与 Public 同网段是同 PublicPrivate每节点 1~4 个独立心跳网段是同 PublicSCAN VIP3 个与 Public 同网段部分场景可同 PublicGNS VIP1 个与 Public 同网段不适用同 PublicStandalone Cluster 支持到 64 节点每个节点直连共享存储通过各自的 ASM 实例或共享文件系统挂载。Domain Services Cluster 则是另一种形态一个或多个节点组成域服务集群集中提供 GIMR、TFA、ASM 存储管理成员集群通过网络路径或直连方式访问分片存储。选哪种模式决定了 GIMR 要不要配、大页要不要多算 1G、GNS 是不是必需。4.2 固定 /etc/hosts 的最小可用方案不启用 GNS 时最省事的做法是 hosts 固定解析 Public 与 PrivateSCAN 走 DNS 的三条 A 记录VIP 在安装时手工指定。这种方案在测试环境足够生产环境如果节点会扩容就要重新考虑。hosts 文件的关键是“每个名字在每台节点上解析结果完全一致”不能靠 localhost 兜底。# 两节点示例节点间必须完全一致 cat /etc/hosts EOF 192.168.204.11 pub19-node1.rac.lab pub19-node1 192.168.204.12 pub19-node2.rac.lab pub19-node2 40.40.40.41 priv19-node1.rac.lab priv19-node1 40.40.40.42 priv19-node2.rac.lab priv19-node2 192.168.204.21 vip19-node1.rac.lab vip19-node1 192.168.204.22 vip19-node2.rac.lab vip19-node2 192.168.204.10 gns19-vip.rac.lab gns19-vip EOF # 逐条验证正向与反向解析反过来解析不出来的名字要补 PTR for h in pub19-node1 pub19-node2 priv19-node1 priv19-node2 vip19-node1 vip19-node2; do getent hosts $h donePrivate 用 40.40.40.0/24 这种与业务网段完全无关的地址段是我习惯的做法能避免路由表误判。getent hosts比ping更准因为它走的是 NSS 解析链和安装器看到的结果一致。反向解析在 CVU 阶段会被检查hosts 方案下如果没配 DNS 反解部分检查项会报 warning不影响安装但要心里有数。4.3 BIND 正反解与 GNS 子域委派要上 GNS就得自己起一个 BIND。手册里的配置分三块named.conf 里声明正解域和两个反解域正解文件里放 A 记录和关键的 NS 委派反解文件里放 PTR。最容易漏的是最后两行委派记录——vip.rac.lab IN NS gns.rac.lab和gns.rac.lab IN A 192.168.204.10它把vip.rac.lab这个子域的解析权交给了 GNS 自己。# 安装 BIND先确认仓库可用 yum install -y bind chroot # named.conf 关键片段正解域 两个反解域 cat /etc/named.conf EOF options { directory /var/named; allow-query { any; }; recursion yes; allow-transfer { none; }; }; zone rac.lab IN { type master; file named.rac.lab; }; zone 204.168.192.in-addr.arpa IN { type master; file named.192.168.204; }; zone 40.40.40.in-addr.arpa IN { type master; file named.40.40.40; }; EOFallow-query { any; }在测试环境可以放开生产环境应限制到集群网段。allow-transfer { none; }禁止区域传送避免解析表被整表拉走。两个反解域分别对应 Public/VIP/SCAN 所在的 192.168.204.0/24 和 Private 所在的 40.40.40.0/24少一个都会让 CVU 的反向解析检查失败。正解文件里除了常规 A 记录重点在末尾两行委派cat /var/named/named.rac.lab EOF $TTL 600 IN SOA rac.lab. admin.rac.lab. ( 2024010101 ; serial 1D ; refresh 1H ; retry 1W ; expire 3H ) ; minimum IN NS master.rac.lab. master IN A 192.168.204.12 scan19.vip.rac.lab. IN A 192.168.204.33 scan19.vip.rac.lab. IN A 192.168.204.34 scan19.vip.rac.lab. IN A 192.168.204.35 pub19-node1.rac.lab. IN A 192.168.204.11 pub19-node2.rac.lab. IN A 192.168.204.12 priv19-node1.rac.lab. IN A 40.40.40.41 priv19-node2.rac.lab. IN A 40.40.40.42 vip19-node1.rac.lab. IN A 192.168.204.21 vip19-node2.rac.lab. IN A 192.168.204.22 vip.rac.lab. IN NS gns.rac.lab. gns.rac.lab. IN A 192.168.204.10 EOF最后两行的含义是vip.rac.lab子域的权威服务器是gns.rac.lab而gns.rac.lab的地址是 192.168.204.10。这解释了为什么 SCAN 域名必须写成scan19.vip.rac.lab这种形式——它要落在被委派的子域下面GNS 才能接管后续的地址分配。如果 SCAN 写成scan19.rac.lab解析请求根本不会转到 GNS安装器就会一直转圈。# 反解文件把正向名字反过来写一遍 cat /var/named/named.192.168.204 EOF $TTL 600 IN SOA rac.lab. admin.rac.lab. ( 2024010101 3H 15M 1W 1D ) IN NS master.rac.lab. 11 IN PTR pub19-node1.rac.lab. 12 IN PTR pub19-node2.rac.lab. 21 IN PTR vip19-node1.rac.lab. 22 IN PTR vip19-node2.rac.lab. 33 IN PTR scan19.vip.rac.lab. 34 IN PTR scan19.vip.rac.lab. 35 IN PTR scan19.vip.rac.lab. EOF systemctl enable --now named named-checkconf named-checkzone rac.lab /var/named/named.rac.lab改完配置先跑named-checkconf和named-checkzone两者都通过再重启服务。验证用digdig 192.168.204.12 scan19.vip.rac.lab应该返回三条 A 记录dig -x 192.168.204.33应该返回 PTR。named-checkzone报 SOA 格式错误时多半是行内注释和括号位置不对逐行对齐即可。4.4 gridSetup.sh 的网络页与 GNS 子域填写到了图形界面这步前面所有的网络规划都要在这里落成参数。启动 gridSetup.sh 之前先设好环境变量解压 GI 介质到目标家目录权限给对然后用 grid 用户执行。# 目录与权限先摆好避免安装器自检报权限错误 mkdir -p /u01/app/grid /u01/app/19.0.0/grid chown -R grid:oinstall /u01/app/grid /u01/app/19.0.0/grid chmod -R 775 /u01 su - grid export CV_ASSUME_DISTIDOEL7.6 # RHEL 7.6 上绕过发行版识别 cd /u01/app/19.0.0/grid ./gridSetup.shCV_ASSUME_DISTID这个变量在 RHEL 小版本与 GI 兼容列表对不上时很有用能让安装器按指定的发行版走校验逻辑。网络页的填写按这个顺序先选 Standalone Cluster 或 Domain Services ClusterPublic 填pub19-node1.rac.labPrivate 填40.40.40.41并指定对应网卡VIP 填192.168.204.21SCAN 名填scan19.vip.rac.lab三条地址由 GNS 或手工给出如果启用 GNSGNS VIP 填192.168.204.10子域填vip.rac.lab。注意Standalone Cluster 在 19c 里可以选择不配 GIMR但一旦选了 GNS 又没配 GIMR某些校验项会给出警告。测试环境可以先关掉 GNS把集群跑通再加 DNS 做地址管理。5. 五类高频翻车点从 THP 残留到 GNS 委派失败的排查路径装过几轮之后会发现失败点高度集中在几个位置而且现象往往和根因隔着两层。这一章按“现象 → 原因 → 解决”记录五个我在实际复现中遇到过的坑每条都给可执行的确认命令。排查的核心思路是不要信界面上显示的状态回到内核和解析层看真实值。5.1 现象THP 显示 never但实例启动仍抖动现象/sys/kernel/mm/transparent_hugepage/enabled已经是neverGI 也能启动但 ASM 实例在高负载时出现延迟毛刺alert 日志里有内存分配相关的等待。原因只改了 enableddefrag 仍是always。内核仍会做内存碎片整理只是不再主动分配大页。另一种情况是改了/etc/default/grub但重建的是 UEFI 路径之外的 grub.cfg重启后/proc/cmdline里根本没有参数。解决两个文件都要确认/proc/cmdline也要回读。三处一致才算真关掉。grep -E enabled|defrag /sys/kernel/mm/transparent_hugepage/* grep -o transparent_hugepage[a-z]* /proc/cmdline如果/proc/cmdline里没有说明 grub 重建路径选错BIOS 机器要重建/boot/grub2/grub.cfgUEFI 机器要重建/boot/efi/EFI/redhat/grub.cfg重建后必须重启。5.2 现象GNS 服务正常SCAN 域名解析不出来现象systemctl status named是 activedig dns-ip gns.rac.lab能返回 192.168.204.10但dig dns-ip scan19.vip.rac.lab返回 NXDOMAIN 或超时。原因正解文件里缺委派记录或者 SCAN 域名不在被委派的子域下。还有一种隐蔽情况dig直接指定了 DNS 服务器地址所以能通但节点上的/etc/resolv.conf没指向这台 DNS安装器走系统解析链时就失败。解决先确认委派两行存在再确认 SCAN 名以vip.rac.lab结尾最后确认 resolv.conf。grep -E NS|gns /var/named/named.rac.lab cat /etc/resolv.conf dig scan19.vip.rac.lab trace | tail -20trace能看到解析链路在哪一跳断掉比反复改配置高效。如果断在本地 DNS说明委派没生效需要rndc reload或重启 named。5.3 现象runcluvfy 报 PRVF 类错误逐条看却都不像问题现象预检输出一堆 PRVF- 开头的条目涉及节点间时间、用户等价性、解析一致性手工验证每项都“本文还有配套的精品资源点击获取
