企业官网建设流程全解析

1. 项目概述：一次物理Standby搭建中RMAN恢复失败的深度复盘

物理Standby数据库是Oracle高可用架构里最经典、最可靠的容灾方案之一。它通过将主库的归档日志实时传输并应用到备库，实现数据级的零丢失保护。但凡在生产环境真正搭过一次完整物理Standby的人，大概率都踩过RMAN恢复阶段报错的坑——尤其是那几个看似“标准错误码”，实则指向千差万别底层问题的组合：RMAN-03002、RMAN-06026、RMAN-06100。这三个错误码经常成套出现，像一套连招，专挑你刚配完DG Broker、心跳正常、归档传输也显示“SUCCESS”之后，在执行RECOVER DATABASE或RESTORE DATABASE时突然亮红灯。我去年在某金融行业客户的灾备系统升级中，就卡在这一步整整36小时，从凌晨三点反复重试到第二天下午，最终发现根源竟是一份被误删的归档日志编号间隙，而这个间隙在主库上早已被自动清理，备库却因网络抖动漏收了其中两段——这种细节，任何官方文档都不会写进“常见问题”章节，但它真实存在，且高频发生。

这篇笔记不是教科书式的错误码字典，而是以一个真实故障现场为切口，把“物理Standby搭建时恢复报错RMAN-03002 RMAN-06026 RMAN-06100”这个标题背后所有隐性知识全部摊开：为什么这三个错误必然成对出现？它们之间是什么调用关系？RMAN-06026说“some targets not found”，到底在找什么target？RMAN-06100强调“no backup or copy of datafile found”，可明明LIST BACKUP能看到备份集——问题出在“可见”和“可用”之间那层薄薄的元数据映射上。我会带你一层层剥开RMAN的恢复决策链：从控制文件里记录的检查点SCN，到归档日志序列号的连续性校验，再到数据文件头中记录的“last change SCN”与归档日志起始SCN的对齐逻辑。这些内容不涉及任何敏感配置，也不依赖特定版本，适用于11gR2至19c所有主流企业版环境。如果你正卡在这个报错上，别急着删控制文件重来，先搞懂这三行错误背后的因果链，90%的情况能5分钟内定位根因。

2. 错误码组合的底层逻辑与调用链解析

2.1 RMAN-03002：只是个“总包工头”的告示牌

RMAN-03002的完整报错通常是：RMAN-03002: failure of {command} command at {time}。注意，它本身不携带任何业务语义，只是一个通用的“上层命令执行失败”通知。比如你执行RESTORE DATABASE，它就告诉你“restore命令失败了”；你执行RECOVER DATABASE，它就告诉你“recover命令失败了”。它的价值在于锚定时间点和操作类型，但绝不揭示失败原因。很多初学者一看到RMAN-03002就慌，其实该忽略它——就像你家电路跳闸，空气开关弹出来（RMAN-03002）只是结果，真正要查的是哪条线路短路、哪个电器过载。在物理Standby恢复场景中，RMAN-03002永远是第一个报出来的，但它后面紧跟的RMAN-06026和RMAN-06100，才是真正的“故障诊断报告”。

提示：下次再看到RMAN-03002，第一反应不是查它，而是立刻翻看紧接着的下两行错误——那才是黄金线索。

2.2 RMAN-06026：目标缺失的“寻人启事”

RMAN-06026的标准文本是：RMAN-06026: some targets not found - aborting restore。关键在“some targets”这个词组。这里的target，不是指数据库、表空间或数据文件名，而是RMAN在恢复计划生成阶段，根据当前控制文件状态推导出的必须存在的归档日志序列号范围。举个具体例子：假设你的备库控制文件里记录的最新数据文件头SCN是12345678，而你最近一次全量备份（比如level 0）完成时，控制文件中记录的checkpoint SCN是12340000。那么RMAN在做RESTORE DATABASE前，会先计算出一个“恢复窗口”：需要从序列号100开始，一直应用到序列号150的归档日志，才能把数据文件从12340000推进到12345678。这个100~150就是RMAN认定的“targets”。如果备库的FRA（快速恢复区）里只存了100~105、110~120、130~150，唯独缺了106~109和121~129，RMAN就会报RMAN-06026，并明确列出缺失的序列号段。它不是说“找不到备份集”，而是说“我规划好的归档日志补丁包，有几块拼图不见了”。

这个机制的设计哲学很务实：RMAN不信任人工判断的“应该够用”，它严格按SCN连续性数学推导出最小必要集合。所以当你看到RMAN-06026，核心动作不是去查备份集是否存在，而是立刻验证归档日志的序列号连续性。方法很简单：在备库执行LIST ARCHIVELOG ALL，然后用SQL查出所有已注册归档的日志序列号，再用Linux的seq和comm命令比对是否连续。我习惯用这条单行命令快速筛查：

sqlplus / as sysdba <<'EOF' set pages 0 feedback off verify off spool /tmp/arch_seq.txt SELECT sequence# FROM v$archived_log ORDER BY sequence#; spool off exit EOF comm -13 <(seq $(head -1 /tmp/arch_seq.txt) $(tail -1 /tmp/arch_seq.txt) | sort) <(sort /tmp/arch_seq.txt)

如果有输出，那就是断点。这个脚本我压在口袋里三年，救了七次场。

2.3 RMAN-06100：数据文件“身份认知错乱”的终极体现

RMAN-06100的报错是：RMAN-06100: no backup or copy of datafile {n} found to restore。表面看是“找不到数据文件备份”，但真相往往更微妙。在物理Standby搭建中，你几乎不会真的没有备份——因为Standby的起点通常是主库的BACKUP AS COPY DATABASE或DUPLICATE TARGET DATABASE FOR STANDBY。问题出在RMAN的“元数据信任链”上。RMAN恢复时，会同时读取三个地方的信息：控制文件里记录的数据文件路径、备份集中记录的文件路径、以及实际磁盘上文件的头部信息（通过dbv或kfed可验证）。如果这三者不一致，RMAN就拒绝使用该备份。

最常见的不一致场景有三种：
第一种是路径映射错误。比如主库备份时数据文件在/u01/oradata/prod/users01.dbf，但备库的DB_FILE_NAME_CONVERT参数没配好，导致控制文件里记录的路径是/u02/oradata/stdby/users01.dbf，而你手动cp过去的文件却放在/u01/oradata/stdby/users01.dbf。RMAN按控制文件去找，自然“找不到”。
第二种是文件头SCN污染。当用dd或cp直接拷贝数据文件后，没用SWITCH DATABASE TO COPY更新控制文件，文件头里的checkpoint SCN还是主库的旧值，与备库控制文件里期望的SCN对不上，RMAN判定“这不是我要的那个副本”。
第三种最隐蔽：备份集损坏但未报错。RMAN的VALIDATE BACKUPSET命令有时会漏检某些块级逻辑损坏，直到恢复时读取到坏块才触发RMAN-06100。这种情况必须用RESTORE VALIDATE DATABASE CHECK LOGICAL来深度扫描。

注意：RMAN-06100和RMAN-06026经常同时出现，但它们指向不同维度的问题。前者是“文件身份认证失败”，后者是“日志链条断裂”。必须分开排查，不能混为一谈。

2.4 三者联动的完整故障链：一个典型现场还原

去年某银行核心系统搭建灾备库时，报错正是这三连：

RMAN-03002: failure of restore database command at 2023-08-15 03:22:17 RMAN-06026: some targets not found - aborting restore RMAN-06100: no backup or copy of datafile 1 found to restore

我们按顺序拆解：
首先，RMAN-03002锁定是restore database失败；
接着，RMAN-06026提示缺失targets，执行LIST ARCHIVELOG ALL发现序列号从23456断到23460，中间缺4个；
最后，RMAN-06100说datafile 1找不到——但LIST COPY OF DATABASE明明显示copy存在。
这时我们用VALIDATE COPY OF DATAFILE 1，返回validation succeeded，说明文件本身完好；再用ALTER DATABASE CREATE DATAFILE '/u01/oradata/stdby/system01.dbf' AS '/u01/oradata/stdby/system01.dbf'强制重建，报错ORA-01119: error in creating database file，提示权限不足；查ls -l才发现，/u01/oradata/stdby/目录属主是oracle:oinstall，但启动数据库的用户是grid:asmadmin，权限组不匹配。原来客户用ASM+文件系统混合部署，忘了给文件系统目录加asmadmin组读写权限。
你看，RMAN-06100在这里根本不是“找不到文件”，而是“找到了但打不开”，而RMAN把它统一归类为“no backup or copy found”。这就是Oracle错误设计的“善意模糊”——它不想让用户陷入权限、SELinux、挂载选项等OS层细节，但代价是增加了排查成本。所以我的经验是：只要RMAN-06100出现，第一件事不是查RMAN目录，而是ls -ld看路径权限、mount | grep oracle看挂载选项、getenforce看SELinux状态。这三步做完，50%的RMAN-06100自动消失。

3. 物理Standby恢复失败的四大高频根因与实操验证法

3.1 根因一：归档日志序列号断点（占所有案例的68%）

这是RMAN-06026的绝对主力场景。断点产生原因五花八门：主库归档路径磁盘满导致归档失败、备库监听器临时宕机错过几秒日志传输、DG Broker配置中LOG_ARCHIVE_DEST_2的SYNC/ASYNC模式切换引发日志丢弃、甚至主库执行ALTER SYSTEM ARCHIVE LOG CURRENT时网络闪断。但无论原因，验证方法唯一：用控制文件的SCN推导理论需求数列，再与实际归档列表比对。

实操步骤分四步：
第一步：获取备库当前控制文件的checkpoint SCN

SELECT checkpoint_change# FROM v$database; -- 假设返回 1567890123

第二步：获取备库最早可用归档日志的first_change#

SELECT MIN(first_change#) FROM v$archived_log WHERE applied='YES'; -- 假设返回 1567800000

第三步：计算理论所需归档序列号范围
这里要用到一个关键公式：sequence# = (SCN - first_change#) / average_scn_per_log + base_sequence。但实际不用算——Oracle内部有更直接的方法。执行：

SELECT thread#, sequence#, first_change#, next_change# FROM v$archived_log WHERE first_change# <= 1567890123 AND next_change# > 1567800000 ORDER BY sequence#;

这个查询会列出所有理论上能覆盖SCN缺口的归档日志。如果结果为空，说明断点太大，必须从主库重新传日志；如果结果不空但COUNT(*)小于理论差值（1567890123-1567800000约等于9000000，按平均每个日志增长10000 SCN算，需要900个日志），那就肯定有断点。

第四步：用Linux命令精确定位断点
前面提到的comm命令是王道，但生产环境常需更直观展示。我写了个小脚本check_arch_gap.sh：

#!/bin/bash # 从v$archived_log导出序列号到/tmp/seq_list.txt sqlplus -s / as sysdba <<'EOF' > /tmp/seq_list.txt SET PAGES 0 FEEDBACK OFF VERIFY OFF SELECT sequence# FROM v$archived_log ORDER BY sequence#; EXIT EOF # 生成理论连续序列 MIN_SEQ=$(head -1 /tmp/seq_list.txt) MAX_SEQ=$(tail -1 /tmp/seq_list.txt) seq $MIN_SEQ $MAX_SEQ > /tmp/theory_seq.txt # 找出差异 diff /tmp/theory_seq.txt /tmp/seq_list.txt | grep "^>" | awk '{print $2}' > /tmp/gap_list.txt if [ -s /tmp/gap_list.txt ]; then echo "发现归档断点：" cat /tmp/gap_list.txt | paste -sd ',' - else echo "归档序列号连续" fi

运行后输出类似发现归档断点：10234,10235,10236,10240,10241，一目了然。这时解决方案只有两个：从主库用scp或rsync手工补传缺失日志，或者用RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT命令让DG自动重传（前提是主库还保留着那些日志）。

3.2 根因二：数据文件副本路径与控制文件记录不一致（占22%）

这问题在跨平台复制或手动迁移时高频出现。典型症状是LIST COPY OF DATABASE能看到文件，但RESTORE DATABASE报RMAN-06100。根源在于RMAN的“三重校验”：控制文件记录路径、备份集元数据路径、磁盘实际路径，三者必须完全一致（包括大小写、符号链接、相对路径等）。

验证方法分三层：
第一层：比对控制文件记录路径

SELECT name FROM v$datafile; -- 返回 /u01/oradata/stdby/system01.dbf

第二层：比对备份集元数据路径

LIST COPY OF DATABASE; -- 查看输出中"Copy of datafile"后的路径，比如显示为 /u01/oradata/prod/system01.dbf

第三层：比对磁盘实际路径

ls -l /u01/oradata/stdby/system01.dbf -- 如果返回"No such file"，说明文件不在那里；如果返回权限错误，说明路径对但权限错

三者不一致时，修复方案有且仅有一个：用SWITCH DATABASE TO COPY强制同步元数据。但注意，这个命令要求文件必须在正确路径且权限正确。所以标准流程是：

1. cp或mv把文件放到控制文件记录的路径；
2. chown oracle:oinstall和chmod 640修正权限；
3. 启动到MOUNT状态；
4. 执行SWITCH DATABASE TO COPY;
5. 再执行RESTORE DATABASE;
   这一步千万不能跳过SWITCH，否则RMAN永远认为“这个文件不是我备份的副本”。

实操心得：我见过最坑的案例是客户用NFS挂载主库备份目录到备库，路径是/backup/nfs/prod/，但DB_FILE_NAME_CONVERT配成了'/backup/nfs/prod/','/u01/oradata/stdby/'，结果RMAN在备份集中读到的路径是/backup/nfs/prod/system01.dbf，而SWITCH后控制文件里写的是/u01/oradata/stdby/system01.dbf，但实际文件还在NFS上！所以SWITCH前务必确认文件物理位置。

3.3 根因三：控制文件自身损坏或版本不匹配（占7%）

物理Standby搭建中，控制文件是整个恢复流程的“大脑”。如果它损坏，RMAN的恢复计划就是无源之水。RMAN-06026和RMAN-06100同时爆发，且LIST BACKUP和LIST COPY都返回空，基本可锁定控制文件问题。但怎么验证？不能直接STARTUP MOUNT看报错，因为Standby的控制文件必须和主库完全一致（包括创建时间戳），否则ALTER DATABASE RECOVER MANAGED STANDBY DATABASE会报ORA-01153。

验证方法是“双盲对比”：
第一步：从主库导出控制文件快照
在主库执行：

ALTER DATABASE BACKUP CONTROLFILE TO TRACE AS '/tmp/controlfile_trace.sql';

这会生成一个包含所有数据文件、日志文件路径及SCN信息的SQL脚本。
第二步：在备库用同样的trace命令生成本地快照

ALTER DATABASE BACKUP CONTROLFILE TO TRACE AS '/tmp/stdby_controlfile_trace.sql';

第三步：用diff对比两个trace文件
重点关注三处：

• CREATE CONTROLFILE语句中的RESETLOGS/NORESETLOGS选项是否一致；
• DATAFILE列表中的文件路径、大小、创建时间是否完全相同；
• LOGFILE组的成员路径和状态是否匹配。
  如果发现差异，比如主库trace里DATAFILE '/u01/oradata/prod/sysaux01.dbf' SIZE 1024M，而备库trace里是SIZE 512M，说明控制文件被意外修改过。此时唯一安全方案是从主库用ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/tmp/standby.ctl';生成新控制文件，再scp到备库替换。

注意：CREATE STANDBY CONTROLFILE命令必须在主库OPEN状态下执行，且执行后主库会自动归档当前日志，确保备库能接上。这是Oracle官方唯一认可的控制文件同步方式，任何手动编辑trace文件重建的方案，都会在后续日志应用时报ORA-00354等严重错误。

3.4 根因四：RMAN通道配置与存储权限冲突（占3%）

这个根因最隐蔽，因为它不报错在RMAN层面，而是静默失败。现象是：RESTORE DATABASE命令执行后，RMAN长时间卡在“starting media recovery”状态，最后超时报RMAN-03002，但V$SESSION_LONGOPS里看不到任何进度。根源往往是RMAN分配的通道（channel）无法访问指定设备。比如你配了ALLOCATE CHANNEL c1 DEVICE TYPE DISK FORMAT '/backup/%U';，但/backup目录属主是root:root，而oracle用户没有写权限；或者用了SBT（第三方备份设备），但libobk.so库路径没加到LD_LIBRARY_PATH。

验证方法分两步：
第一步：检查RMAN通道实际行为
在RMAN中执行：

SHOW ALL; -- 看DEVICE TYPE和FORMAT参数 ALLOCATE CHANNEL c1 DEVICE TYPE DISK FORMAT '/backup/%U'; RUN { ALLOCATE CHANNEL c2 DEVICE TYPE DISK FORMAT '/backup/%U'; RESTORE DATABASE; }

然后立刻在操作系统层监控：

# 查看RMAN进程打开了哪些文件 lsof -p $(pgrep -f "rman.*target") | grep "/backup" # 如果没有任何输出，说明通道根本没成功挂载路径

第二步：模拟RMAN的IO行为
用oracle用户手动测试路径可写性：

sudo -u oracle bash -c "echo test > /backup/test_write.txt 2>/dev/null && echo 'OK' || echo 'FAIL'" # 如果返回FAIL，就是权限问题

解决方案就是修正权限：

chown oracle:oinstall /backup chmod 755 /backup # 如果是ASM，确保oracle用户在asmadmin组里 usermod -a -G asmadmin oracle

这个步骤看似简单，但在容器化或K8s环境中极易被忽略——因为Pod的volume mount默认是root权限，oracle用户进去就是“游客”。

4. 搭建物理Standby时的预防性检查清单与避坑指南

4.1 搭建前必做的五项静态检查

很多RMAN恢复失败，其实在搭建前就埋下了雷。以下是我在所有客户现场强制执行的Pre-Check清单，每项都对应一个高频故障点：

特别强调第3项：DB_FILE_NAME_CONVERT。我见过太多客户写成'/u01/oradata/prod','/u01/oradata/stdby'（少了一个/），结果RMAN把/u01/oradata/prod/system01.dbf映射成/u01/oradata/stdbysystem01.dbf（自动拼接），路径不存在，直接报RMAN-06100。这个/不是语法糖，是Oracle字符串处理的硬规则。

4.2 恢复过程中的动态监控三板斧

一旦开始RESTORE或RECOVER，就不能干等。我用三个实时命令构建监控闭环：

第一板斧：盯住RMAN会话的等待事件

SELECT sid, event, p1text, p1, p2text, p2, p3text, p3 FROM v$session_wait WHERE program LIKE '%rman%';

如果EVENT长期是'control file sequential read'，说明在读控制文件，正常；如果是'db file sequential read'且P1（file#）是某个数据文件号，说明正在读那个文件，也正常；但如果EVENT是'SQL*Net message from client'且持续超过5分钟，基本可判定RMAN客户端卡死，需要kill -9进程重启。

第二板斧：看V$RECOVERY_PROGRESS的实时进度

SELECT type, item, units, sofar, total, (sofar/total)*100 pct_done FROM v$recovery_progress WHERE total > 0;

这个视图会显示Media Recovery、Active Apply Rate等关键指标。如果sofar长期不增长，而total固定，说明日志应用卡在某个SCN。这时立刻查V$MANAGED_STANDBY：

SELECT process, status, sequence#, block#, blocks FROM v$managed_standby WHERE process IN ('MRP0','RFS');

如果MRP0的STATUS是APPLYING_LOG但SEQUENCE#停滞，就是日志断点；如果RFS的STATUS是IDLE，说明主库没传新日志过来。

第三板斧：用strace抓RMAN系统调用
当以上SQL都看不出问题时，祭出终极武器：

# 找到RMAN后台进程PID ps -ef \| grep "rman.*target" \| grep -v grep \| awk '{print $2}' # 用strace跟踪 strace -p <PID> -e trace=open,read,write,close -o /tmp/rman_strace.log 2>&1 & # 运行几分钟后Ctrl+C，分析log grep "ENOENT\|EACCES" /tmp/rman_strace.log

ENOENT表示文件不存在，EACCES表示权限拒绝。这个方法能精准定位到RMAN试图打开哪个路径失败，比任何日志都直接。

4.3 我的私藏应急手册：三分钟快速恢复法

当客户电话打来“RMAN恢复卡住了，马上要割接”，我有套标准化应急流程，亲测平均3分27秒解决：

Step 1：终止当前RMAN会话

# 在RMAN中 ABORT; # 或在OS层 ps -ef \| grep "rman.*target" \| grep -v grep \| awk '{print $2}' \| xargs kill -9

Step 2：强制同步归档日志

-- 在备库 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; -- 在主库 ALTER SYSTEM ARCHIVE LOG CURRENT; -- 等待10秒，再在备库 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;

这会触发DG Broker自动重传所有缺失日志。90%的情况下，5分钟内V$ARCHIVED_LOG的APPLIED列就变成YES。

Step 3：如果Step 2失败，执行“裸奔恢复”
所谓裸奔，就是绕过RMAN，用最原始的cp+RECOVER：

# 在主库 cp /u01/fast_recovery_area/PROD/archivelog/2023_08_15/o1_mf_1_10234_*.arc /tmp/ # scp到备库 scp /tmp/o1_mf_1_10234_*.arc oracle@stdby:/u01/fast_recovery_area/STDY/archivelog/2023_08_15/ # 在备库 ALTER DATABASE REGISTER LOGFILE '/u01/fast_recovery_area/STDY/archivelog/2023_08_15/o1_mf_1_10234_*.arc'; RECOVER DATABASE UNTIL SEQUENCE 10234 THREAD 1;

REGISTER LOGFILE命令会强制把手工传入的日志注册进控制文件，RECOVER则直接应用。这套组合拳，我称之为“Oracle的急救心肺复苏术”，在RMAN彻底失灵时屡试不爽。

最后分享一个血泪教训：某次客户环境，RECOVER DATABASE报RMAN-06100，我按常规流程查权限、查路径，折腾两小时。最后发现，他们用的是Oracle 12c的Multitenant架构，而RESTORE DATABASE命令默认只恢复CDB，没管PDB。必须显式加上PLUGGABLE DATABASE pdb1参数。所以现在我所有脚本开头第一行都是：SELECT con_id, name FROM v$pdbs;——先看清自己在跟谁对话。

5. 常见问题速查表与独家排查技巧

5.1 问题速查表：按现象反向定位根因

5.2 独家排查技巧：那些文档里不会写的细节

技巧一：“RMAN-06100的隐身文件”检测法
有时候LIST COPY看不到文件，但磁盘上确实存在。这是因为RMAN的catalog只记录“已注册”的副本。用以下命令强制扫描整个磁盘：

CROSSCHECK COPY; DELETE EXPIRED COPY;

CROSSCHECK会遍历所有DB_RECOVERY_FILE_DEST下的文件，把未注册的副本标记为EXPIRED；DELETE EXPIRED则清理元数据。之后再LIST COPY，就能看到所有物理存在的副本。这个技巧救过我三次，因为客户用cp复制后忘了CATALOG COPY。

技巧二：用DBMS_BACKUP_RESTORE包绕过RMAN限制
当RMAN彻底罢工，可以用Oracle内置PL/SQL包手动恢复：

DECLARE devtype VARCHAR2(256); BEGIN devtype := sys.dbms_backup_restore.deviceAllocate(type => '', ident => 't1'); sys.dbms_backup_restore.restoreSetDatafile; sys.dbms_backup_restore.restoreDatafileTo(dfNumber => 1, toname => '/u01/oradata/stdby/system01.dbf'); sys.dbms_backup_restore.restoreBackupPiece( done => FALSE, handle => '/backup/PROD/backupset_20230815_01.bkp', params => NULL ); sys.dbms_backup_restore.deviceDeallocate; END; /

这个包不走RMAN元数据校验，直接IO操作，适合极端情况。但风险极高，必须在Mount状态下执行，且无法回滚。

技巧三：归档日志“幽灵断点”的终极验证
有些断点LIST ARCHIVELOG查不到，因为日志被DELETE INPUT删了，但控制文件还记着。用这个SQL挖出所有“幽灵日志”：

SELECT sequence#, first_time, next_time, deleted FROM v$archived_log WHERE sequence# BETWEEN 100 AND 150 ORDER BY sequence#;

如果DELETED='YES'，说明日志已被清理，但控制文件没更新。这时必须用CHANGE ARCHIVELOG ALL UNCATALOG;清除控制文件残留记录，再手工补传。

我的个人体会是：RMAN报错从来不是RMAN的问题，而是它忠实地反映了底层数据状态的不一致。每一次RMAN-03002 RMAN-06026 RMAN-06100的组合，都是Oracle在用最严厉的方式