目的

本文件为用户提供了ORAchk（Oracle配置审计工具）运行和维护的信息。该工具的目的是在Oracle系统中的审计各种重要的配置设置。

注：在2.2.4版本中RACcheck已更名为ORAchk以反映其检查Oracle越来越多产品的健康的不断扩展的作用。请参考RACcheck配置审计工具的声明 –更名为ORAchk（文件编号1591208.1），了解更多详细信息。版本12.1.0.2.3将是raccheck脚本与ORAchk一起发行的最后一个版本。客户应该转化过来，使用任何自动化或环境配置中的orachk脚本。

在以下分类中工具审计配置的设置：

OS内核参数
OS包
许多其他OS配置设置
CRS/Grid Infrastructure
RDBMS
ASM
数据库参数和配置设置
为目标版本2.0.3及以上升级准备评估

范围

ORAchk健康评估工具的范围是Oracle数据库服务器，Grid Infrastructure，Oracle数据库，硬件，操作系统和RAC软件。从ORAchk2.2.0开始，ORAchk功能扩展到Oracle单实例数据库，Oracle Restrat System以及RAC单节点配置

支持的平台

现在，该工具受以下UNIX平台支持：

Intel Linux* (Oracle Linux/RedHat 5, 6, 7 and SuSE 9,10, 11, 12)
Linux on System Z (RedHat 6, 7 and SuSE 12)
Oracle Solaris SPARC (Solaris 10 and 11)
Oracle Solaris x86-64 (Solaris 10 and 11)
AIX **
HPUX**
MS Windows (2008 and 2012)***

*对Linux Itanium没有计划支持

* 32位平台只通过命令“./orachk-ebs32bit”受32位EBS环境支持

**需要bash shell3.2或更高版本要安装在系统

***需要Cygwin（详情见附录O）

支持的数据库版本

现在，该工具受以下数据库版本支持：

10gR2
11gR1
11gR2
12cR1

组件

该工具包含一个脚本和两个驱动文件（以及其他一些文件）。

orachk (以及向后兼容性的raccheck)
dat
dat

功能

ORAchk是非侵入的且不会改变环境中的任何东西，除非详情如下：

假设SSH用户等效性的RDBMS软件所有者将所有被审计，以便它在遥控器上执行命令的数据库服务器中配置的 – 数据库服务器节点。如果工具确定该用户等效不成立，将提供给暂时或永久设置它在用户的选项。如果用户选择临时设置SSH用户等效那么脚本会做这样的工具执行的时间，但是，它可以将系统恢复到它发现SSH用户等效原来的状态。对于那些希望配置SSH用户等效性的工具外（如果尚未配置），请参阅My Oracle Support说明：1。

注：SSH用户等效只对于为支持集群运行Grid Infrastructure的这些系统是必须的，这对单实例数据库或Oracle重启配置不是必需的。

– ORAchk创建许多小的输出文件到有需要进行评估的数据被采集

– ORAchk动态创建并执行一些脚本来完成一些数据收集

– ORAchk在本身后清理创建的，且不需要作为集合的一部分的任何临时文件。

ORAchk询问系统以确定Oracle栈组件的状态（即，Grid Infrastructure，RDBMS，RAC等）以及它们是否被安装且/或运行。根据每个组件的状态，该工具运行适当的计划和审计检查。如果由于本地环境的配置，工具无法正确地确定所需的环境信息，请参阅故障排除部分。

监视的守护程序 – ORAchk自动在后台运行监视命令执行进展情况的守护程序。如果由于某种原因，该工具运行的其中一个命令应挂起或需要比预期更长的时间，该监视守护程序会在可配置的超时后杀掉挂起命令，以便主要的执行能进行。如果出现这种情况，那么集合或被挂起的命令被跳过，且在最后的输出报告中会有标记。如果默认的超时时间太短，请参阅有关RAT_TIMEOUT，并RAT_ROOT_TIMEOUT参数调整的故障排除部分。

如果ORAchk的驱动程序文件都超过90天，那驱动程序文件被认为是“陈旧”，并且脚本会告知用户这些文件。该工具及其驱动程序文件（套件）的新版本必须从My Oracle Support Note: 1268927.1中获得。

当ORAchk完成收集并分析它而产生了一个详细的HTML格式的报告，同时生成了一个输出.zip文件。此输出.zip文件可提供给Oracle Support，以便在SR需要被记录时作进一步分析。详细的报告将包含优势/影响，风险和行为/修复信息。在许多情况下，它也将参考公共文件，包含问题相关的其他信息，以及如何解决它。

审计检查的结果可以选择上传到数据库表用于报告。下面有这个问题的更多细节。

在某些情况下，客户可能希望在共享文件系统上对ORAchk暂存，以便它可以从各种系统进行访问，但保持在单一的位置，而不是被复制到每个可以用到的集群上。该工具的默认行为是在工具被暂存的位置创建一个子目录及其输出文件。如果暂存区域是一个只读文件系统，或者如果出于任何原因，用户想要在别处创建输出，那就有可用于这一目的环境变量。RAT_OUTPUT参数可被设置为任何有效的可写位置且输出将在那里被创建。

使用注意事项

默认的临时工作目录位置是启动ORAchk的用户ID的主目录。例如，如果“oracle”用户ID被用于启动ORAchk且“oracle”用户ID的主目录为“/home/oracle”，那么默认的临时工作

目录位于“/home/oracle”。有可能在执行ORAchk之前，通过设置“RAT_TMPDIR”环境变量（如export RAT_TMPDIR=/ tmp）来改变默认位置。

注：如果你在使用root的SUDO权限（见附录M），你想改变默认的临时工作目录位置，必须在“/ etc/ sudoers” 文件中体现你选择的位置。在这种配置下，在个服务器的“/ etc/ sudoers” 文件必须包含以下行：

oracle ALL=(root) NOPASSWD:/tmp/root_exachk.sh

建议暂存工具包并在单个数据库的本地文件系统操作以获得性能最优。

为了获得最大效用，当Grid Infrastructure和至少一个数据库启动和运行时执行ORAchk。

尽管ORAchk是影响最小的工具，但在系统上的负载达到最小时执行它是最佳做法。

为了避免在网络连接的工作站或笔记本电脑上的终端会话运行工具可能出现的问题，考虑在运行使用VNC，这样如果有一个网络中断，工具将继续处理并完成。

如果工具由于某种原因应执行失败，它可以从开始被重新运行，但该工具从故障点“不可恢复”。

在2.2.1版本中，ORAchk有在所有节点上并行执行的能力。为了利用ROOT专项检查的优势，同时仍然允许并行执行，你要在安装系统上EXPECT工具或配置SUDO供ORAchk使用，在附录M有描述。

从ORAchk版本2.2.5开始，数据库集合开始并行执行。要选择数据库集合slave进程的非默认的最大数量（默认为自动计算），使用-dbparallel [n]。例如，要将默认计算的值更改为30，你要执行“./orachk -dbparallel 30”。如果由于某种原因，你想禁用并行的数据库集合，使用-dbserial选项。

注：并行度越高，资源被消耗越多，但所用的时间被减少。除了能将并行slave的数量设置高于默认值，还可以将并行slave的数量设置低于默认值。这些做法是有原因的。例如，在整个系统被维护并启动后，在实际的用户被允许登陆系统之前，你可能需要使用大量的并行slave完成ORAchk，越快越好。再比如，在一个繁忙的生产系统中，可以使用比默认值更少的数目，但比以串行方式运行更多，以更快地运行，又对运行系统产生较少的影响。

从12.1.0.2.1开始，有可用于ORAchk的两种基本执行模型
以“root”用户ID执行- 在这种模式下，“root”用户ID用来启动一个完整的ORAchk运行。以“root”用户ID运行的ORAchk过程将使用“su”命令作为RDBMS或grid home权限的较低的所有者之一来执行命令。较低的权限帐户不会有提升权限以执行“root”级检查的能力。这种方法在角色分离的环境，或有更严格的安全模型的环境有优势。

作为RDBMS home所有者执行 – 在此方法中，ORAchk从RDBMS或Grid home所有者用户ID启动。启动ORAchk 的用户ID必须有提高“root”用户ID的权限的能力来运行“root”级检查。这可以通过提供的“root”用户ID的密码，设置“sudo”（如附录中描述），或无密码的SSH连接来完成。这意味着一个较低的权限帐户必须设置为能够切换到“root”用户ID。该方法可能需要在角色分离环境中的多次运行，且更严格的安全要求可能不允许提高权限。

什么时候运行ORAchk

初始Oracle RAC部署之后
在计划的系统维护之前
在计划的系统维护之后
每3个月至少一次

使用

如果安装了Oracle软件，仅作为Oracle RDBMS软件所有者（oracle）在数据库服务器上运行该工具。

该工具可以使用下列参数运行：

Compare two different Exalogic rack and see if both are from the same release.Pass directory name or zip file as

<Exalogic collection1> & <Exalogic collection2>(applicable for Exalogic only)

-merge [-force]

Pass comma separated collection names(directory or zip files) to merge collections and prepare single report. eg:- ./orachk -merge orachk_hostname1_db1_120213_163405.zip,orachk_hostname2_db2_120213_164826.zip

-force

Merge collections from dom0 and domu or global and local zones.

eg:- ./orachk -merge orachk_hostname1_db1_120213_163405.zip,orachk_hostname2_db2_120213_164826.zip -force

-tag <tagname>

Appends <tagname> to Report Name. <Tagname> must contain only alphanumeric characters. for eg: ./orachk -tag newtag123 will append ‘newtag123’ to report name like

‘orachk_hostname1_db1_100914_123456_newtag123.html’

Auto Restart Options:

-auto_restart -h: Prints help for this option

-<initsetup|initrmsetup|initcheck|initpresetup>

initsetup : Setup auto restart. Auto restart functionality automatically brings up orachk daemon when node starts initrmsetup : Remove auto restart functionality

initcheck : Check if auto restart functionality is setup or not

initpresetup : Sets root user equivalency for COMPUTE, STORAGE and IBSWITCHES.(root equivalency for COMPUTE nodes is mandatory for setting up auto restart functionality)

Daemon Options:

status : Check if the orachk daemon is running

info : Print information about running orachk daemon

stop_client : Stop the orachk daemon client

schedule ID

nextautorun [-id <ID>] : print the next auto run time

if ‘-id <ID>’ is specified, it will print the next auto run time for specified autorun

-h : Prints help for this option

-daemon

run orachk only if daemon is running

-nodaemon

Do not use daemon to run orachk [-id <ID>] -set

configure orachk daemon parameter like ‘param1=value1;param2=value2… ‘

if ‘-id <ID>’ is specified, it will configure orachk daemon parameter(s) for specified autorun schedule ID Supported parameters are:-

(Deprecated) – AUTORUN_INTERVAL <n[d|h]> :- Automatic rerun interval in daemon mode.Set it zero to disable automatic rerun which is zero.

AUTORUN_SCHEDULE * * * * :- Automatic run at specific time in daemon mode. AUTORUN_INTERVAL will be ignored when AUTORUN_SCHEDULE is used.

– – – –

? ? ? ?

? ? ? +—– day of week (0 – 6) (0 to 6 are Sunday to Saturday)

? ? +———- month (1 – 12)

? +————— day of month (1 – 31)

+——————– hour (0 – 23)

example: orachk -set ‘AUTORUN_SCHEDULE=8,20 * * 2,5’ will schedule runs on Tuesday and Friday at 8 and 20 hour.

AUTORUN_FLAGS <flags> : orachk flags to use for auto runs.

example: orachk -set ‘AUTORUN_INTERVAL=12h;AUTORUN_FLAGS=-profile sysadmin’ to run sysadmin profile every 12 hours orachk -set ‘AUTORUN_INTERVAL=2d;AUTORUN_FLAGS=-profile dba’ to run dba profile once every 2 days.

NOTIFICATION_EMAIL : Comma separated list of email addresses used for notifications by daemon if mail server is

configured.

PASSWORD_CHECK_INTERVAL <number of hours> : Interval to verify passwords in daemon mode

COLLECTION_RETENTION <number of days> : Purge orachk collection directories and zip files older than specified days. [-id <ID>] -unset <parameter | all>

unset the parameter

if ‘-id <ID>’ is specified, it will unset the parameter for specified autorun schedule ID example: orachk -unset AUTORUN_SCHEDULE

[-id <ID>] -get <parameter | all> Print the value of parameter.

if ‘-id <ID>’ is specified, it will print the value of parameter for specified autorun schedule ID

-vmguest

Pass comma separated filenames containing exalogic guest VM list(applicable for Exalogic only)

-hybrid [-phy]

phy :Pass comma separated physical compute nodes(applicable for Exalogic only) eg:- ./orachk -hybrid -phy phy_node1,phy_node2

Profile Run Options:

-profile

Pass specific profile. With -h prints help.

List of supported profiles:

-excludeprofile

Pass specific profile.

List of supported profiles is same as for -profile.

-check

To execute specific set of checks, pass check_ids at command prompt With -h prints help.

-excludecheck

To exclude specific set of checks, pass check_ids at command prompt With -h prints help.

acchk options:

-acchk

Env variables to be set: RAT_AC_ASMJAR=path to asm-all-5.0.3.jar RAT_JAVA_HOME=path to jdk8

RAT_AC_JARDIR=Directory where jar files are present for concrete class RAT_AC_TRCDIR=Directory where trace files are present for coverage class

Runs acchk. Expects env variables to be set

Run orachk without any

If the above env variables are set, orachk can be run without any parameter to run acchk.

Passing values in command line instead of env

./orachk -acchk -javahome <path to jdk8> -asmhome <path to asm-all-5.0.3.jar > -appjar <directory where jar files are present for concrete class > -apptrc <directory where trace files are present for coverage class>

Optional variable RAT_ACTRACEFILE_WINDOW variable can be set to <number of days> . Based on this value, files older than the RAT_ACTRACEFILE_WINDOW days are ignored.

With -h prints help.

-cells

Pass comma separated storage server names to run orachk only on selected storage servers.

-ibswitches

Pass comma separated infiniband switch names to run orachk only on selected infiniband switches.

-zfsnodes

Pass comma separated ZFS storage appliance names to run orachk only on selected storage appliances.

-zfssa

Pass comma separated ZFS storage appliance names to run orachk.

-dbserial

Run SQL, SQL_COLLECT and OS Checks in serial

-dbparallel [n]

Run SQL, SQL_COLLECT and OS Checks in parallel.

n : Specified number of Child processes. Default is 25% of CPUs.

Identity Management Options:

-idm -h: Prints help for Identity Management

idmpreinstall : Run all preinstall checks on Identity Management System idmpostinstall : Run all postinstall checks on Identity Management System idmruntime : Run all runtime checks on Identity Management System idmdbpreinstall : Run preinstall database checks on Identity Management System idmpdbostinstall: Run postinstall database checks on Identity Management System idmdbruntime : Run runtime database checks on Identity Management System idm_config : Pass OAM, OIM and one of the OUD host from clusters.

idmdiscargs : Pass arguments to Identity Management Discovery Tool. idmhcargs : Pass arguments to Identity Management Healthcheck Tool.

example :

Run preinstall checks

orachk -idmpreinstall -idm_config “OUD_HOST=h1,h2;OIM_HOST=h3,h4;OAM_HOST=h5,h6,h7;OHS_HOST=h8,h9”

Run preinstall database checks orachk -idmdbpreinstall

Run postinstall checks on single node Identity Management setup orachk -idmpostinstall -idm_config “singlenode”

Run runtime checks on multinode Identity Management setup

orachk -idmruntime -idm_config “OUD_HOST=host1,host2;OAM_HOST=host3;OIM_HOST=host4”

Run OIM runtime checks on multinode Identity Management setup

orachk -idmruntime -idm_config “OUD_HOST=host1,host2;OAM_HOST=host3;OIM_HOST=host4” -profile “OIM”

Run OIM & OAM postinstall checks on single node Identity Management setup orachk -idmpostinstall -idm_config “singlenode” -profile “OIM,OAM”

细粒度检查控制

从版本12.1.0.2.5开始，细粒度检查控制语法就出现了。这些控件可以被用于限制检查并向一个或多个检查报告。以类似的方式，一个或多个检查可以被排除，而无需创建一个排除文件。

要将报告限制到一个或多个特定检查，通过单击在报告总结部分，靠近报告上方的“Show Check Ids” 的链接，check_ids可以从ORAchk html报告获得。

./orachk –check <check_id1> <check_id2> Similarly to exclude one or more checks

./orachk –exclude_check <check_id1> <check_id2>

缓存和重新使用发现信息

从12.1.0.2.5版本开始，缓存数据库信息的支持被增加。此功能是一种性能优化设计，用于减少运行时间。如果环境数据库配置是稳定的，不会经常变化，那么数据库的信息可以被缓存，使得ORAchk不必每次动态运行来获得信息。命令行语法如下：

./orachk –create_cache

./orachk –use_cache

./orachk –refresh_cache

-create_cache可以在守护进程模式启动时指定。 -use_cache可用于后续的守护程序客户端运行。如有在系统上的数据库阵容的更改，-应使用refresh_cache，例如，增加了新的数据库或数据库被删除。

运行ORAchk指南

如果oracle用户在系统上存在，且所有的Oracle组件被安装或运行（CRS，RDBMS，ASM），建议运行ORAchk作为oracle（或RDBMS软件安装）用户。该工具将需要执行一些需要root权限的集合，在这种情况下，它会显示以下输出（或类似）：

注: 建议以数据库软件所有者（如oracle）运行该工具。用户可能以Grid Infrastructure软件所有者（如grid）运行该工具，它会收集相同的数据，但数据库凭据必须手动提供以执行数据库相关的审计检查。通常情况下，当以oracle运行时，客户会有为Oracle数据库软件所有者设置的OS验证，且不再需要数据库的登录认证。如果集群和数据库被安装并运行，最好以oracle（或拥有oracle数据库软件安装的任何用户）运行此工具。如果由于某种原因，你要以其他用户运行工具，参考在故障排除部分的验证数据库认证，了解在运行该工具前如何验证数据库认证的其他信息。

用户只能使用由工具包分配的驱动程序文件，且驱动程序文件不应被手动编辑。该工具的新版本需要新的驱动程序文件。

如何交互运行 ORAchk

以 Oracle RDBMS 软件安装所有者(如果安装了Oracle产品，否则以root登录) 登录到系统 – 详情参见使用注意事项

将正确的zip 包暂存到它自己的目录，节点在工具将被执行的位置

解压zip包，将脚本和驱动程序文件留在同一个目录下

验证orachk的权限是755（-rwxr-xr-x）。如果权限当前没有设置为755，将orachk的权限设置为如下：

调用工具，如下：

在阅读和理解所有的消息时按照提示操作。ORAchk的Q＆A过程将类似于下图所示：

Note: If you chose option 1, to provide root password when prompted, you will be prompted once for each node during the data collection phase for the nodes (unless the EXPECT utility is installed, in which case you will only be prompted once). If you do not enter the root password in a timely way (within RACCHECK_TIMEOUT) then the root privileged collections and audit checks for that node will be skipped.

Starting with ORAchk 2.2.2, the sysadmin profile may be run independently as the root user allowing for the root checks to be performed independently of the non-root checks (./orachk -profile sysadmin).

完成后，如下（或类似的）将被显示：

此时你可以查看以上输出中显示的HTML报告。如果ORAchk有被推荐为解决方案一部分的动态SR，上传orachk_ *.zip包到该SR。

如何静默运行ORAchk

注: 只有当客户不需要使用orachk守护功能时才需要进行以下配置。参见“ORAchk守护模式操作”一节，了解orachk守护进程的更多细节。

ORAchk可以选择在“静默”或“非交互”模式运行来启用调度和自动控制。在静默模式执行ORAchk必须要满足一些特定条件。出于这个原因，本节被分成几个小节，ORAchk静默条件和静默运行ORAchk。

前提条件

为了静默执行ORAchk，SSH用户等效性是强制性的。这就是说，你必须为系统之间的RDBMS软件所有者（如oracle）配置SSH用户等效性，用于ORAchk和其他所有集群节点的实际执行。有关配置用户等效说明，请参阅My Oracle Support Note: 372795.1。配置完成后，通过执行以下命令，用适当的远程群集节点替换“<dbServerName>”来验证作为RDBMS软件所有者（如oracle）的SSH用户等效性配置的正确配置：

If the result of the above command is similar to “Permission denied (publickey,gssapi-with- mic,password)” then the SSH user equivalence is not properly configured. Consult My Oracle Support Note: 372795.1 for details on configuring SSH user equivalence. 如果上述命令的结果与“权限被拒绝（公钥，gssapi-with- mic,password）”类似，那么SSH用户等效性没有正确配置。参见My Oracle SupportNote: 372795.1 ，了解配置SSH用户等效性的详情。

注: SSH用户等效仅对于运行Grid Infrastructure来支持集群的这些系统是必须的，对于单实例数据库或Oracle重新启动配置来说不需要。

如之前提到的，为了利用ORAchk的完整功能的优势，需要root权限来运行root特定检查。为了便于在静默模式下的这些检查，我们必须配置无密码的SUDO和利用-s选项（之后会更详细）来执行ORAchk。有关配置SUDO用于ORAchk的教程参见附录M。

注: 如果sudo在你的环境中不允许，这一步可以省略。在这种情况下，你仍然可以使用-S选项（之后会更详细）静默执行ORAchk而无需root特定检查。消除root特定检查会限制ORAchk的功能，所以不是建议执行ORAchk的方法。

静默/非交互运行ORAchk

以Oracle RDBMS软件安装所有者（如果安装了Oracle的产品，否则以root身份登录）登录到系统 — 参阅使用注意事项的详细信息。

将正确的zip 包暂存到它自己的目录，节点在工具将被执行的位置

解压zip包，将脚本和驱动程序文件留在同一个目录下

验证orachk的权限是755（-rwxr-xr-x）。如果权限当前没有设置为755，将orachk的权限设置为如下：

要静默运行ORAchk ，你需要根据配置指定以下参数之一：

-s – 当Oracle用户可以无需密码，SUDO来root时，无人参与模式执行

-S – 无需root密码和root权限集合/审计, 无人参与模式执行

注: 强烈建议执行无密码SUDO来为/$HOME/root_orachk.sh root以获得ORAchk工具的全部功能。请参阅附录M了解如何为ORAchk配置SUDO的细节。

假设SUDO已经被正确配置，ORAchk（见附录M）现在可以被静默执行如下：

注: 如果SUDO尚未配置，必须指定-S选项代替-s选项。

根据ORAchk从集群拉出的信息，ORAchk现在会在静默模式下执行。在静默模式下，在本地节点上运行的被定义为集群资源的所有数据库都会执行采集数据和审计检查。

完成后，以下（或类似）ORAchk输出可供查看：

注: 如果ORAchk有被推荐为解决方案一部分的动态SR，将由工具最近运行产生的orachk_ *.zip上传到SR。

ORAchk守护模式操作

交互启动ORAchk 守护模式

ORAchk 2.2.2版本引入了守护进程的功能，允许在一定间隔内的非交互式（批处理或静默模式）执行。

注: 当在守护进程模式运行ORAchk，最近和下一个最新的（如果有的话）集合报告被自动对比。如果NOTIFICATION_EMAIL地址被配置，一个摘要及报告的附件和对比报告将通过电子邮件被发送。

在守护模式下运行 ORAchk之前，建议自定义守护参数（使用- set 标识）：

AUTORUN_INTERVAL – 定义了ORAchk将被执行的时间间隔，具体为天或小时数（(<d|h>）。
PASSWORD_CHECK_INTERVAL – 定义了当守护进程启动时，运行的守护进程验证输入密码的频率（以小时为单位）。如果一个无效的密码被发现（由于密码更改），守护程序将停止，通知将通过守护程序日志（log）和电子邮件提供（如果已配置）。
NOTIFICATION_EMAIL – 允许ORAchk守护进程的邮件通知。可以设置多个邮箱，用逗号分隔。
AUTORUN_FLAGS – 允许ORAchk自动运行的执行参数的设置。可用参数在本文的使用章节中列出。
COLLECTION_RETENTION:- 如果由orachk守护程序创建的文件比collection_retention 数更早几天，通过执行定期的orachk可以清除这些文件。
INFO:- orachk –d info 命令会显示关于orachk守护进程的信息，例如，它从哪里从何时开始运行等。
STOP_CLIENT:- 当你停止orachk守护程序，而一个orachk客户端仍在运行，orachk守护进程也将继续运行。使用带有-d标志的stop_client选项能停止当前在进行的客户端，然后停止orachk守护程序，使用户不必等到客户端运行结束。

将每个参数填入以分号分隔的列表，使多个参数可以在单一执行中被设置。要设置守护程序每天运行，在详细模式下，为守护进程通知指定电子邮件地址并每小时检查更改的密码，作为将启动守护模式下的ORAchk（全部在一行）的用户ID，执行以下命令：

要查看当前ORAchk守护值，作为启动守护进程的用户ID，执行“./ORAchk – get <parameter_name> | all”：

ORAchk 2.2.3版本引入了在特定时间运行ORAchk的能力，使用“AUTORUN_SCHEDULE”功能。在此关键字后，预计有四个字段。首先是一天中的小时，0-23为有效值。第二个是一个月的天，1-31为有效值。三是月，以1-12为有效值。第四是一周中的某一天，以0-6为有效值。该字段可以是单个值或逗号分隔。例如，要设置ORAchk守护进程在每月的周二的15，16，17小时运行：

该参数也能在ORAchk守护进程启动后被设置或更改。

注: 强烈建议将NOTIFICATION_EMAIL 和PASSWORD_CHECK_INTERVAL 配置为最小值。

在正确ORAchk后，守护进程参数被设置来配置守护进程，启动ORAchk守护进程：

ORAchk将显示标准的交互式图形用户界面来收集所需信息并启动守护进程。当输入收集过程完成后，你会看到类似的输出：

ORAchk守护进程的当前状态可以通过执行以下来查看：

通过执行以下，ORAchk守护进程能在任何时间停止：

一旦ORAchk守护进程正在运行，ORAchk会自动按照指定的AUTORUN_INTERVAL运行。接下来的收集时间可以从守护进程查询，如下所示：

ORAchk也可以通过守护程序按需（用户初始的）执行，只要执行不带任何参数的 “orachk”，作为从该ORAchk守护进程启动的同一目录启动该守护进程的用户。这个执行是非交互式的（守护进程将参数发生到所有提示符），但会在屏幕上显示类似标准执行的输出：

注: 如果你的ORAchk守护进程在运行，你想在标准的交互模式下执行ORAchk，可以指定“-nodaemon”标识。

由给定用户启动的ORAchk守护程序无法被不同的用户使用来运行ORAchk，比如，如果用户1启动守护进程，那用户2不能使用ORAchk守护进程在非交互模式下运行ORAchk。其实，要使用ORAchk守护程序，你必须是相同的用户，必须在启动守护进程的同一个目录下按需启动运行。

一旦ORAchk守护进程被启动，它将继续在后台运行，直到守护进程的显示停止（orachk –d stop）或发生以下任何一个条件：

 在该守护程序运行的服务器被重启或发生故障。

 如果密码在任何节点上被更改，守护进程将停止，一个条目将被添加到ORAchk_daemon.log，同时被发送电子邮件至NOTIFICATION_EMAIL。PASSWORD_CHECK_INTERVAL参数可以调整，以保证所要求的密码的有效性。

 如果ORAchk脚本被更改或由于你启动守护程序而更换了新的脚本，进一步需求以及自动运行将不会成功。你需要重启守护进程和新的脚本来进一步运行。

注: 如果系统配置被更改 (如，添加/删除节点，添加/删除实例等)，你需要重启ORAchk 守护进程使配置更改被识别。

自动启动非交互ORAchk 守护进程模式

在orachk 2.2.4中，可以选择守护进程模式自动启动功能。此功能需要与root等效的无密码ssh用户配置为用户配置自动启动功能（例如，root或oracle）。如果找不到运行orachk用户的无密码的ssh等效用户，orachk将能够在用户选项中配置。只要orachk自动启动功能被配置，无密码的ssh用户等效性留在原处。解除配置orachk守护进程模式自动启动功能将ssh配置恢复到自动启动功能被配置之前的状态。如果在节点由于任何原因被重启后，有要求orachk在守护模式非交互启动，这个功能会非常有用。

orachk守护程序自动启动配置有三个新的选项：

-initcheck:- 检查orachk守护程序是否在节点重启时被配置为自动启动或者守护程序是否因某种原因出现故障

-initsetup:-通过orachk脚本与init集成，配置orachk守护程序自动启动模式

-initrmsetup:-删除orachk守护程序自动启动模式和init集成与orachk脚本

在守护进程中配置多个运行

ORAchk2.2.5引入在ORAchk守护进程中定义多个运行的能力。例如，在一定时间运行“sysadmin”配置文件的配置，以及在不同时间运行“dba”配置文件的设置，两者都在相同的守护进程中。

为了保持配置的分离，2.2.5版本引入了“-id<ID>”命令行限定符。当使用多个配置时这是必需的，且它识别出分离的配置。

在这个例子中，我们将在同一守护进程中创建两个配置，一个运行系统管理员sysadmin配置文件，而另一个运行dba配置文件。

ORAchk已被安装，我们cd到安装目录。这不是作用分隔的环境，“oracle”用户ID同时拥有grid和RDBMS home。

验证守护程序未被配置或运行：

配置第一个 “ID”：

配置第二个 “ID”

查看配置：

注: 通过指定–id <ID> 选项，每个配置文件都能被单独查看。

最终启动守护进程：

使用配置文件运行检查的子集

在ORAchk 中使用配置文件有三个原因

运行检查的子集： – 如果用户只想执行集群软件相关的检查，而不是运行完整的健康检查，并忽视其余检查，你可以使用像./orachk-profile集群软件的clusteware集群软件配置文件，它只会执行集群软件相关的检查。
以root运行orachk： – 即使Oracle数据库在运行，只要使用像./orachk-profilesysadmin一样的syadmin配置文件，还是可以以root用户运行orachk。
支持基于角色的健康检查： – 可能有不同的人对操作系统和数据库进行管理，并可能执行分离的健康检查。使用系统管理员配置文件可以进行OS健康检查，且DBA可以使用DBA的资料做数据库健康检查。

用ORAchk执行报告比较

在2.2.1版本中，ORAchk有在两个 ORAchk报告之间执行报告比较的功能。这使得成功因素和最佳实践，规划后的维护等在一个用户友好的HTML报告之内随着时间的推移而变化。这么做的前提条件是为了维持那些ORAchk运行的会被用于报告对比的ORAchk输出目录，.zip输出文件或ORAchk HTML 报告。下面的步骤提供执行ORAchk报告对比的例子：

确定在报告比较中使用的报告（新的和旧的）：

注: 本例使用输出目录，但是，HTML报告或输出.zip文件也可用于比较功能。

我们要使用二月八号和二月27号的报告进行报告比较：

注: 当在守护进程模式运行ORAchk时，最新和下一个最新的（如果有的话）集合报告被自动对比。如果配置了NOTIFICATION_EMAIL地址，一份带报告和比较报告的附件的摘要会通过电子邮件被发送。

合并ORAchk报告

有些时候，当你有orachk的多个报告，你可能希望将它们合并成单个的报告来看。例如，

由于客户的安全策略，集群节点之间的无密码ssh用户等效性不能使每个集群节点必须本地运行orachk。每个节点的报告可以合并成单个报告。
如果数据库管理员不知道root密码并使用DBA配置文件运行orachk，以及系统管理员知道root密码并使用系统管理员配置文件作为root运行orachk。这两份报告可以合并成一个报告。

要合并报告。只要将包含需要合并的报告的orachk zip文件或orachk输出目录的列表发送，orachk会将这些独立报告合并为单个的报告。

Eg., $ ./orachk –merge <zipfile 1> <zip file 2> > <zip file 3> > <zip file …>

在升级准备模式下运行ORAchk

从2.1.5版本开始，ORAchk（Oracle配置审计工具）可以用来获得一个自动11.2.0.3（或更高版本）升级准备评估。在ORAchk升级准备评估的目标是使针对版本11.2.0.3及以上的Oracle RAC和Oracle集群软件升级规划过程尽可能顺利，即通过自动完成许多在升级相关的文件中详述的手动前后检查。

ORAchk Upgrade Readiness has 2 modes, a pre-upgrade check and a post-upgrade check. The pre- upgrade check is to be executed during the planning phase of the upgrade process; this will ensure that enough time is available to rectify potential issues prior to the upgrade itself. The post-upgrademode ensures the health of GI and Database (from an Upgrade perspective). Below is a summary list of what to expect from ORAchk Upgrade Readiness: ORAchk升级准备有2种模式，升级前检查和升级后的检查。升级前检查是在升级过程中的规划阶段执行;这将确保有足够的时间可用来纠正在升级之前本身的潜在问题。升级后模式确保（从一个升级的角度）GI和数据库的健康。下面是ORAchk升级准备的摘要列表：

目标集群软件和数据库版本必须为11.2.0.3以上
在升级前模式中，工具会检测在集群软件中自动注册的所有数据库，并显示要在其上进行升级前检查的数据库列表。
在升级后模式中，工具会检测在集群软件中自动注册的所有数据库，并显示要在其上进行升级后检查的数据库列表。如果任何在11.2.0.3版本前的数据库被选择时，升级后检查将跳过它们。
在这两种模式中，工具将适当检查集群软件和操作系统。
当工具完成，用户将被引用到HTML格式的报告，它将包含结果以及更多的细节和信息的链接。

下面的步骤提供执行ORAchk升级准备评估的一个例子：

在你的未决RAC升级的升级规划阶段，在升级前模式中，作为Oracle RDBMS软件所有者执行ORAchk，然后按照屏幕上的提示：

注: 强烈建议升级前检查在升级的规划阶段执行。这将使规划和实施的结果由ORAchk强调。

当你已经成功升级到2.0.3或更高（GI和/或RDBMS），在升级后模式作为Oracle RDBMS软件所有者执行ORAchk，然后按照屏幕上的提示：

其他有用的选项

dbnone:- 在版本2.2.4中引入，此选项不接受任何值。如果在运行orachk时，在命令提示符下指定了此选项，用户不会被提示选择任何运行中的数据库，且没有数据库检查将被运行。
dball:- 在2.2.4版本中引入，此选项也不接受任何价值。如果运行orachk时，在命令提示符下指定了此选项，用户将不会被提示，但所有正在运行的数据库将被检查。
dbnames:- 在2.2.4版本中引入，这个选项需要在命令提示符下传送数据库列表。用户不会被提示选择任何其他运行中的数据库。此选项实际上类似于在地方环境问题章节讲到的RAT_DBNAMES environemt变量，但它在命令行而不是在环境中指定。
nopass:- 在2.2.4版本中引入，这个选项也没有任何参数。如果使用此选项，发生的检查将不会被包含在HTML报告中，也不会被上传到数据库。如果数据库上传功能根据附录F配置 – ORAchk结果和数据库的修补程序会被上传进行报告。
noscore:- 在2.2.4版中引入的noscore选项允许用户省略出现在ORAchk HTML报告顶部的健康评分。

附录A – 故障排除

调试ORAchk

要生成ORAchk的调试输出，用“-debug”命令行选项执行ORAchk。 ORAchk将创建一个调试文件，其名称基于一个时间戳，其中包括：

在本地节点的程序的bash -x
在所有远程节点的程序的bash –x
所有动态生成的，在orachk中称为脚本的bash -x

调试ORAchk守护进程

注: 每个客户端运行将在工作目录中生成一个日志。在客户端运行日志中的信息量取决于守护进程在调试还是非调试模式下运行。

Start_debug:-要解决守护进程问题，用户可以使用-d标志和start_debug选项在调试模式下启动orachk守护程序。守护程序的调试信息将被写入在orachk工作目录下生成的log。如果守护进程在调试模式下启动，则客户端日志将包含：
1. 在本地节点的程序的‘bash –x’
2. 在所有远程节点的程序的‘bash –x’
3. 所有动态生成的，在orachk中称为脚本的bash -x

如果守护进程在非调试模式（orachk -d启动）被启动，则客户端日志将包含正常程序的执行。这将有利于在调试守护程序有关的问题，特别是密码检查问题和客户端运行提交和客户端运行有关的问题（本地节点，远程节点和中间脚本）。

控制行为的环境变量

运行时命令超时:

RAT_TIMEOUT –默认为90秒，如果任何非root权限的命令默认超时时间不够长，则看门狗守护进程会杀掉子进程，且所需的数据将丢失。如果发生了这个情况，可以通过在脚本执行环境中的设置环境变量增加超时时间：

RAT_ROOT_TIMEOUT -默认为300秒，该工具将为在集群中的每个节点执行一次root权限的数据集。如果root权限的数据集的默认超时时间不够长。则看门狗守护进程会杀掉子进程，且该节点所需的数据将丢失。如果发生了这个情况，可以通过设置在脚本执行环境中设置这个环境变量增加超时时间：

注: 如果遇到了任何超时的情况，最好确定延迟的原因并进行纠正。在系统上负荷最少的时间运行该工具。丢失的数据集合将限制工具的值。

log 有错误：

当为工具检查orachk_error.log，一些错误将很可能被列入。有些是预期的错误，不表示任何问题。这些错误会被重定向并“吸纳”进error.log中，以防止它们被报告到屏幕并杂乱地显示。所以不要报告任何下列错误来支持。

例如，类似如下的错误可能会被多次报告（每次对应每个节点的每个Oracle软件home）：

这些错误类型发生在角色分离的环境中，当作为RDBMS软件所有者运行的工具尝试使用opatch列出其他用户（grid，或其他数据库的home所有者）home下的补丁。所以当opatch被调用为这些其他用户列出补丁时会出现错误，因为当前用户不具有对其他home的权限。在这些情况下，opatch错误被忽略，且这些home的补丁通过其他方式收集。

此外，类似于下面的错误是可忽略的：

行号可能随时间而改变，但这个错误只表示我们期待一个整数返回值，而没有找到值（即空），所以shell返回该错误，试图作比较。相同的命令能重复多次产生此错误，每个节点一次。

远程root登录问题

如果远程root登录不被SSH允许，具有root权限的命令将不会在如上所述的选项2的情况下工作。为了验证oracle软件所有者（如oracle），用户需要在不工作的节点手动执行下面的命令，并确保它得到如下输出。如果远程root登录不工作，则该工具将无法检查远程节点。如果要对于运行该工具只是暂时的，请让系统管理员来进行更正。

如果由SSH配置了远程root登录，如何验证预期的输出：

如果远程root登录可配置，编辑/ etc/ ssh / sshd_config文件，如下所示：

现在，在集群的所有节点上以root执行以下命令。

本地环境问题

该工具尝试从环境（操作系统和OCR）获取所有数据，但由于本地系统偏差，有时该工具并不如预期工作是可能的，且预期和测试每一个可能的方案是很难的。因此，一些环境变量的支持被列入为用户重写工具的默认行为，或给它所需的信息使其按预期工作提供了一种方法。变量及其使用情况如下：

RAT_INV_LOC – 如果oraInst.loc文件不在预期的位置，如： /u01/app/oraInventory，用户可能需要指定oraInventory目录的确切位置。

RAT_CRS_HOME -如果工具无法取得正确的CRS_HOME路径，设置此变量。如果用户知道安装了集群软件，但工具认为没有，他/她可以判断是不是需要这个变量。

RAT_ORACLE_HOME -如果工具无法获得在集群中注册的数据库的正确ORACLE_HOME路径，设置这个变量。如果用户知道安装了数据库软件但在工具显示信息为软件没有安装，他们将能够决定是否需要该变量。该工具将为在RAT_ORACLE_HOME指定的home运行的数据库执行最佳实践和建议的修补程序检查。

RAT_ASM_HOME – 如果工具无法从集群软件获取正确的ASM_HOME路径。如果用户知道ASM软件被安装在单独的home，但工具显示信息为软件没有安装，他们将能够决定是否需要该变量。

RAT_OS -如果工具不当获取所需的平台。该工具会提示用户由于不正确检测和不支持的平台，获取的平台需要的数据不能找到。

RAT_DB -如果工具不当生成了不正确的数据库版本

RAT_DBNAMES – 如果工具没有从集群软件获得有效的数据库名称，可以指定由空格分隔的数据库列表，则该工具会使用该类别而不是从集群软件得到的，例如，导出RAT_DBNAMES=”ORCL ORADB PROD”。如果要指定多个数据库，只使用双引号。注意，如果你配置RAT_DBNAMES作为在集群软件注册的数据库的子集，且在集群软件中发现被注册的所有数据库的补丁库检查了建议的补丁，那你也应该配置RAT_DBHOMES。

RAT_DBHOMES – 如果RAT_DBNAMES被设置，那么默认下建议的补丁分析将仅限于在RAT_DBNAMES中指定的数据库列表的home。如果对其他数据库home执行推荐的补丁分析比对在RAT_DBNAMES指定的home更可取，那么对推荐补丁需要检查home的数据库指定其由空格分隔的列表，例如假设导出RAT_DBNAMES =”ORCL ORADB”，但即使PROD数据库关闭，你也想要PROD数据库home，以进行检查，然后导出RAT_DBHOMES =“”ORCL ORADB PROD”。这样的话，ORCL和ORADB数据库的最佳实践将被检查，但对于ORCL，ORADB和PROD的home，推荐的补丁将被检查。要指定多个数据库，使用双引号。

RAT_SSHELL – 覆盖默认安全shell的位置，以防SSH不在预期的位置（即，/usr/bin/ssh）。如果ssh命令返回错误“-bash：在”-bash: /usr/bin/ssh -q: No such file or directory “，那么可能是因为ssh不在预期位置，且这个变量可以将工具重定向到正确的位置。

RAT_SCOPY – 覆盖默认安全副本位置，以防scp不在预期的位置（即，在/usr/bin/scp）。如果scp命令将返回错误“usr/bin/scp -q: No such file or directory”，那么它可能是因为scp不在预期的位置，且这个变量可以将工具重定向到正确的位置。

Linux “预期” 工具故障排除

ORAchk使用“预期”工具来回答的密码提示以连接到远程节点进行密码验证，以及执行root集合，无需默认下记录实际的连接过程。有两个ORAchk环境变量能被设置来帮助调试远程目标连接的问题。

RAT_EXPECT_DEBUG -如果这个变量设置为“-d”（破折号d，不是下划线d），预期命令跟踪将被激活，且跟踪信息被写入标准输出。例如，“export RAT_EXPECT_DEBUG=-d”。

RAT_EXPECT_STRACE_DEBUG –如果这个变量设置为“strace”，strace调用预期命令，且跟踪信息被写入标准输出。例如，“export RAT_EXPECT_STRACE_DEBUG=strace”。

通过改变这两个变量的组合，可使用三种级别的预期连接跟踪。

注: 这两个变量只应设置在甲骨文支持或发展的方向。它们通常用于与其它变量和用户界面选项的组合来限制跟踪期间收集的数据量，以及捕获标准输出的“脚本”命令。它们不应该被设为一个完整orachk运行，因为这将产生大量的数据，且如果不使用“脚本”命令，跟踪数据将简单地在屏幕上滚动并丢失！

数据库登录问题：

核查数据库认证 – 如果你打算作为用户而非数据库软件安装所有者（root或grid）运行该工具，且如果你在连接到数据库时遇到问题，那么执行以下步骤：

如果连接到数据库的这种方法行不通，那么该工具也将无法连接。考虑以Oracle数据库软件的安装所有者运行该工具。

用户配置文件：

在用户配置文件中出现提示符（读-p）或陷阱会导致在执行期间工具挂起作为在运行时的.profile文件。出于这个原因，该工具检查在这些语句环境中的.profile文件，并显示一条消息，告诉用户暂时在所有节点的语句注释这些语句。

ORAchk 在SuSe 报告 “-bash: ./orachk: /bin/env: bad interpreter: No such file or directory” 在 SuSe, 执行 ORAchk 之前，你必须软链接 /usr/bin/env 到所有节点上的 /bin/env (在 -s/usr/bin/env /bin/env ) 。

附录 B – 如何获取支持

If problems are encountered either at runtime or if there are questions about the content of the findings of the tool, please post your issues/questions/concerns to the ORAchk thread within the ORAch k Thread of the Scalability RAC My Oracle Support Community. 无论在运行时遇到问题或者有关于该工具的结果有问题，请将你的情况/问题/顾虑发表到在可扩展性RAC My Oracle Support社区的ORAchk主题中的ORAchk主题。

附录 C – 运行ORAchk应该要多久

The time it takes to run the tool will vary based on the number of nodes in a cluster, CPU load, network latency, etc. Normally the entire process takes only a few minutes per node (i.e., less than 5 minutes per node). This is just a general guideline but if it takes substantially more time than this then there may be some other problem that needs to be investigated. Experience in the field has been that it normally takes about an hour for a 10 node cluster. It normally takes about 10 minutes for a two node system. In both cases those times include the tool environmental discovery phase and the entry of passwords. Adjust expectations accordingly for different sized systems or very busy systems. 运行工具需要的时间将根据集群中节点的数量，CPU负载，网络延迟，等等而变化。通常，整个过程只需每节点几分钟（即，每个节点少于5分钟）。这只是一般的指南，但如果比这个时间需要更多的时间，那么可能有其他一些问题需要调查。在该领域的经验是，10个节点的集群通常需要大约一个小时。它通常用于两个节点的系统需要大约10分钟。在这两种情况下，这些时间包括工具环境发现阶段和密码的输入。根据实际情况对不同规模的系统或非常繁忙的系统调整预期。

附录 D – 由ORAchk处理密码

该工具不储存或保存任何密码，无论是操作系统还是数据库。对于root密码，密码的处理将取决于预期的工具是否被安装。

当预期没有显示（除OEL5的所有平台为默认），root密码提示符被延迟，且用户必须密切监视工具执行并根据提示交互输入密码，在集群一个节点一次。

The tool leverages the EXPECT utility which is shipped by default as part of the OEL5 distribution for interactive password automation (see http://expect.sourceforge.org). Expect can be installed on other Linux distributions in order to automate interactive password handling. 该工具利用默认为分布交互式密码自动化（见http://expect.sourceforge.org）的OEL5发行版的一部分的EXPECT工具。Expect可安装在其他Linux发行版，来自动化交互密码的处理。

当发现EXPECT时，root密码在过程的开头被 “收集”且expect会在节点需要root密码提示符时提供它们。这样工具可以继续，而无需来自用户的进一步输入。用户会被提问集群的所有数据库服务器的root密码是否相同。如果用户回答“是”（默认），则root密码会被提示输入并确认一次，然后该密码将用于集群中的所有节点。如果用户回答集群的所有节点的root密码是不一样的，则该工具会提示并对集群的每个节点验证root密码。

同样地，当发现EXPECT，在验证root密码时用户将有三次机会输入正确的密码。如果用户在三次尝试之后没有输入正确的密码，该工具将移动到下一个节点，并显示一个消息，说明该密码仍然是不正确的，然后取决于从该节点收集的数据的检查将被跳过。此时，用户可以取消工具执行并解决问题，或继续但理解有价值的数据可能从报告中消失。解决此问题并重新开始比丢失数据好多了。

When EXPECT is utilized it is also possible that between the time that the root passwords are entered and validated and nodes for those passwords are reached that the passwords could have been changed. In that case a message will appear in the on-screen output stating that the password must have been changed and that the collections for that node will be skipped which means the checks for that node will also be skipped. The user can either allow the tool to continue to completion knowing that data and checks will be skipped or cancel tool execution (Control-C) and resolve the problem and try again. It is better to resolve the problem and start over than to be missing data. 当使用EXPECT时，在root密码输入和验证与达到这些密码的节点的时间内密码可以被更改。在这种情况下，消息会显示在屏幕上的输出，指出该密码已被更改，并且集合该节点将被跳过，这意味着该检查该节点也将被跳过。用户既可以让工具继续完成（了解数据和检查将被跳过）或关闭工具执行（Control -C）并解决问题，然后重试。解决问题并重新开始比丢失数据更好。

In any case, any checks that are skipped (for any reason) will be logged and the reports listed at the end of tool execution will list any checks that were skipped and on which nodes. 在任何情况下，（因任何原因）被跳过的检查都将被记录，而列在工具执行最后的报告将列出所有被跳过的检查和在哪个节点。

“-debug” 选项和密码

Because of the nature of debug operations within the bash shell, the “-debug” output file (and possibly others) will contain the strings that were entered in response to the prompts for operating system user passwords, and optionally the database login username and password when operating system authentication is not configured. 由于在bash shell中调试操作的特性，当操作系统验证未被配置时，“-debug”输出文件（也可能是其他）将包含被输入以对应操作系统用户密码提示的字符串，以及可选的数据库的登录用户名和密码。

With 12.1.0.2.1, unless an ORAchk execution is abnormally terminated (kill -9, database server crash, etc), the ORAchk utility removes these strings by default. 在12.1.0.2.1中，除非ORAchk执行异常终止（kill-9，数据库服务器崩溃，等等），ORAchk工具会默认删除这些字符串。

If you do not wish to remove the password strings for some reason, use the following environment variable to preserve the original “-debug” output file and make a second file without the password strings: 如果出于某种原因你不想删除密码字符串，使用下面的环境变量，保留原有的“-debug”输出文件并创建第二个没有密码字符串的文件：

After using the RAT_KEEP_ORIG_DEBUG_FILE environment variable, you will see two files similar to these shown: 使用RAT_KEEP_ORIG_DEBUG_FILE环境变量后，你会看到两个文件类似于如下所示：

The “.orig” file contains the password strings. “.orig”文件包含密码字符串。

注: 如果使用“-debug”选项的ORAchk运行异常终止，建议手动验证ORAchk被启动的目录，包含对应提示的密码字符串的文件的时间戳输出目录，并编辑返回的文件来替换发现的带一个随机字符串的密码字符串。

例如 (密码字符串 guest1 和tooeasy, ORAchk 从/home/oracle/121021 /password_test启动):

附录 E – 多个数据库支持

The ORAchk tool is designed for multiple database support. The tool will present a list of running databases which are registered in the Grid Infrastructure. The user may choose one, all or enter a comma separated list of numbers which designate the databases listed. It is not necessary to stage the tool on multiple nodes in order to check database instances running on other nodes of the cluster. 该ORAchk工具是专为多数据库支持设计的。该工具将展示登记在Grid Infrastructure的运行中数据库的列表。用户可以选择一个，全部或输入以逗号分隔的指定列出的数据库号码的列表。这对于多个节点上工具的暂存以检查在集群的其他节点上运行的数据库实例是不必要的。

All database logins are accomplished by the use of local bequeath connections and assume the existence of OS authentication in the database for the user executing the tool. In some configurations there could be multiple database homes all owned by the same OS user (e.g., oracle) or in others there could be any number of database homes all owned by different OS users. In the former case, run the tool as “oracle”. In the latter case, stage and run the tool as the OS user which owns the RDBMS home which has the largest number of database instances running from that home as that user will not be able to login into database instances running from homes which it does not own. In order to scan the other databases the tool needs to be staged and run under each database home user account. 所有的数据库登录通过使用本地遗留的连接完成，假设在数据库中有为用户执行工具的OS认证。在某些配置中可能有由同一个操作系统的用户（例如，oracle）拥有的多个数据库home，或在其他可能有由不同操作系统用户拥有的个数据库home。在前一个情况下，以“oracle”运行工具。在后一种情况下，暂存并运行该工具作为拥有RDBMS home，其拥有从该home运行的数据库实例的最大数目，因为用户无法从它不拥有的home登录到数据库实例中。为了扫描其他数据库，该工具需要被暂存并在每个数据库home用户帐户下运行。

附录 F –上传ORAchk结果和补丁到数据库以进行报告Uploading ORAchk Results and Patches to a Database for Reporting

For customers who have a large number of systems and databases it would be useful to upload the results of the audit checks done by the tool and/or the list of installed patches into database tables for use as a source of data for reporting. 对于拥有大量的系统和数据库的用户来说，上传由工具和/或安装的补丁列表到数据库表中以用作数据源进行报告的审计检查结果是有用的。

Starting with ORAchk 2.2.4 Oracle now provides the ORAchk Collection Manager application. Collection Manager is Application Express (APEX) which provides an enterprise wide central repository for ALL ORAchk (and Exachk) collections. The APEX frontend provides an easy to use dashboard interface which users can track, trend, compare and report upon ORAchk findings. ORAchk Collection manager is the preferred approach to reporting on ORAchk collections. The Collection Manager application is bundled with ORAchk (CollectionManager_App.sql). For more information on ORAchk Collection Manager please see the Collection Manager Users Guide found in MOS Note: 1268927.2. 从ORAchk 2.2.4开始，甲骨文现在提供了ORAchk集合管理器应用。集合管理器是快捷应用（APEX），为所有ORAchk（和Exachk）集合提供了一个企业范围的中央存储库。 APEX的前端提供了一个易于使用的仪表板界面，用户可以跟踪，查看趋势，比较并根据ORAchk调查结果报告。 ORAchk集合管理器是对ORAchk集合报告的首选方法。集合管理器应用与ORAchk（CollectionManager_App.sql）捆绑在一起。有关ORAchk集合管理器的详细信息，请参见MOS注释中的集合管理器用户指南：1268927.2。

In order to support this feature a number of environment variables need to be set in the execution environment and three tables need to be created to receive the data, one for the audit check results, one for the patches installed on the systems and one to store the zipped archives that result from the collections: 为了支持此功能，一些环境变量需要在执行环境中设置，且需要出具三个表以接收数据，一个用于审计检查结果，一个用于安装在系统中的补丁，和一个用于存储由集合生成的压缩档案：

AUDITCHECK_RESULT AUDITCHECK_PATCH_RESULT RCA13_DOCS

Reporting Table Specifications报告表规范

注: If you plan on deploying ORAchk Collection manager, the reporting schema documented below will be created when deploying Collection Manager in APEX. 如果你计划部署ORAchk集合管理器，下面介绍的报告模式将在APEX中部署集合管理器时创建。

Results table specification结果表规范(e.g. auditcheck_result):

Version 2.2 added several additional columns to this table. Existing ORAchk users who are using the Database reporting features in ORAchk versions less than 2.2 MUST add these additional columns.

The DDL to add this column is as follows: 2.2版增加了几个附加列到此表。正在使用低于ORAchk2.2版本的数据库报告功能的现有ORAchk用户必须添加这些附加列。

加入此列的DDL如下：

Version 2.2.3 added 2 additional columns and constraints to the auditcheck_result table. Again, existing ORAchk users who are using the Database reporting features in 2.2 MUST add these additional columns and constrains when upgrading to ORAchk 2.2.3: 版本2.2.3增加了2个额外的列和约束到auditcheck_result表。同样，在2.2版本使用数据库报告功能的现有ORAchk用户在升级到2.2.3 ORAchk时必须添加这些额外的列和约束：

Version 12.1.0.2.1 added another 2 additional columns and constraints to the auditcheck_result table. Again, existing ORAchk users who are using the Database reporting features in 12.1.0.2.1 MUST add these additional columns and constrains when upgrading to ORAchk 12.1.0.2.1: 版本12.1.0.2.1增加了2个额外的列和约束到auditcheck_result表。同样，正在使用12.1.0.2.1数据库报表功能的现有ORAchk用户在升级到ORAchk12.1.0.2.1时必须添加这些额外的列和约束：

Full DDL for the Results Table: 结果表的完整的DDL：

Patch table specification (e.g. auditcheck_patch_result): 补丁表规范（例如auditcheck_patch_result）

Version 12.1.0.2.3 added 1 additional the auditcheck_patch_result table. 版本12.1.0.2.3增加1个额外的auditcheck_patch_result表。

RCA13_DOCS表的DDL：

Environment variables (with example settings): 环境变量（示例的设置）：

注: Use the fully qualified address (as in the example above) for the connect string rather than an alias from the tnsnames.ora file so that it is not necessary to rely on tnsnames.ora file name resolution on all the servers where the tool might be run. The double quotes should be included. 使用完全限定的地址（如以上示例），用于连接字符串而不是来自tnsnames.ora文件的别名，这样就不必依靠tnsnames.ora文件名称解析在工具可能运行的所有服务器上。双引号应包括在内。

When the first four above environment variables are set in the execution environment the tool will assume that the intent is to upload the data into the tables and at the end of the process it will attempt to upload the data. This process relies upon the environment being properly set, i.e. the connect string must be reachable, the username and password must be correct and the table name must be correct. If the tool is unable to connect to the database a message to that effect will be written to the log. If the RAT_UPLOAD_ORACLE_HOME variable is set the tool will invoke sqlplus from that home rather than attempting to invoke sqlplus from the current $ORACLE_HOME derived by the tool. If any of the first four environment variables are not set then the tool will not attempt to upload the data. 当前四个以上的环境变量是在执行环境中设置的，该工具将假定意图是将数据上传到表，且在过程的最后，它会尝试上载数据。这个过程依赖于环境被正确设置，即连接字符串必须可访问，用户名和密码必须是正确的，且表名必须是正确的。如果工具无法连接到数据库，该效果的信息将被写入到日志中。如果RAT_UPLOAD_ORACLE_HOME变量被设置，该工具将从home调用sqlplus而不是试图从由工具导出的当前的$ ORACLE_HOME调用sqlplus中。如果前四个环境变量中任何一个未设置，那么工具将不会尝试上载数据。

附录 G – 可选地排除审计检查

要在HTML报告生成前排除审计检查，建设中已经安装了ORAchk脚本和驱动程序文件所在的同一目录下名为“excluded_check_ids.txt”的文本文件。

“excluded_check_ids.txt”包含要被跳过的检查的识别号码，每行一个。每个检查被分配一个唯一检查标识号，一旦分配不会更改。有些检查将需要一个检查标识号被完全跳过，有的需要两个。如果一个检查，并在“exachk.log”文件中同时具有“COLLECTION_NAME”和“AUDIT CHECK NAME”，在“excluded_check_ids.txt”中需要有两个条目。如果检查在“exachk.log”文件中仅有一个“AUDIT CHECK NAME”，这将需要“excluded_check_ids.txt”中只有一个条目。

从HTML报告确定检查ID Determining Check IDs from an HTML Report

从2.2.3版本开始，在HTML报告中有一个切换按钮，使检查识别号码可见或不可见。 “Show Check Ids”链接就在HTML报告的“Table of Contents”的部分下。

当点击“Show Check Ids”链接后，在报告表中的行展开以显示检查ID号：

Check Id	Status	Type	Message	Etc.
DCDB11F4CA7C5701E04313C0E50AB5D3	FAIL	OS Check	vm.min_free_kbytes should be set as recommended.	Etc.

“Show Check Ids” 链接也更改为 “Hide Check Ids”。

当点击 “Hide Check Ids” 链接后，在报告表中的行收起，以隐藏检查ID号：

Status	Type	Message	Status On	Details
FAIL	OS Check	vm.min_free_kbytes should be set as recommended.	All Database Servers	View

要在下一个ORAchk运行期间排除特定的检查，主要 “Show Check Ids”，并将这些检查ID从HTML报告复制到ORAchk“包”被提取的目录中的“excluded_check_ids.txt”。

从日志文件确定检查ID

要找到需要排除的检查ID号，搜索你想从“orachk.log”文件的HTML报告排除的检查的名称。这需要使用之前完整ORAchk运行的“orachk.log”文件。在2.2.2版本中，你会发现在从运行的目录下创建了“log”子目录中的“orachk.log”文件。例如，如果在运行生成了名为“orachk_ratlnx01_mydb_052413_181326”的子目录，“orachk.log”文件将在：“orachk_ratlnx01_mydb_052413_181326/log/ orachk.log”。

要确定检查是否可以被排除以及它是否需要一个或两个检查ID号，可以grep通过“orachk.log”文件，从HTML报告中找到检查名称。一旦你找到了检查名称，在编辑器中打开“orachk.log”文件弄搜索检查名称字符串。每个检查在“orachk.log”文件中有与它相关联的文本块，通常之后跟着由“ – ”组成的一行。检查ID号将在虚线上方。对于某些检查，可以有一个COLLECTION_NAME以及一个AUDIT_CHECK_NAME。

要在下一个ORAchk运行时排除特定的检查，只要将orachk.log文件“CHECK_ID =”后的字符串复制到ORAchk“包”被提取的目录中的“excluded_check_ids.txt”。要完全排除检查和其收集的数据，你最好同时排除COLLECTION_NAME和AUDIT_CHECK_NAME检查ID（如适用）。

基于配置文件排除检查

用户可以使用orachk 2.2.4中引入的称为excludeprofile的新选项，根据一个配置文件来排除检查。当该工具在运行且被排除的配置文件将被列在报告头部时，excludeprofile后配置文件中的检查将不会被执行。

从现有的HTML报告中删除检查

从ORAchk 2.2.3开始，你现在有从现有的HTML报表中删除检查的功能。要做到这一点，点击目录表下的“Remove finding from report”链接。这将在HTML报告中每个审计检查的旁边显示X。要删除一个给定的检查，只需点击X。删除了检查后，你可以点击“Hide remove Buttons”链接，同样在目录表的下方，显示修改后的报告。

注: 使用上述方法删除检查实际上并没有修改HTML报告。要回退更改，你只要重新加载浏览器中的报告。如果你想使更改永久在报告中，必须使用浏览器的“保存网页”功能。

注: 当将结果上传到前面提到的ORAchk集合管理器应用时，它也支持基于业务单位，系统和独立集合，排除（忽略）在应用中的调查结果。详见ORAchk集合管理器安装和用户指南，但此功能为排除或忽略检查结果提供了灵活性。

附录 H –用户ID和密码的特殊注意事项

作为使用该工具时提供更高的安全性的方法，密码不被存储。该工具使用操作系统或标准的Oracle用户名和密码认证机制。

如果执行该工具的用户具有为Oracle的OS认证设置的账户，那么数据库登录不需要用户名和密码。但是，如果用户没有设置数据库访问权限的OS认证，那么用户将被标准Oracle数据库验证提示符提升。

附录 I –输出目录的特殊说明

要限制安全漏洞，该工具输出目录的权限应尽可能严格设置。输出目录可以包含敏感的配置信息，且当没有其他机制可用时，还能包含临时数据集合文件。

附录 J – 输出文件维护

每当ORAchk运行时它总会使用以“orachk”开头的格式创建一个子目录并包括日期和时间（例如，orachk_SIEBXL_072611_141001）和包含子目录的内容（例如，orachk_SIEBXL_072611_141001.zip）的.zip存档，其与工具本身在文件系统的同一层级。子目录和.zip文件的总大小在文件系统最好小于5M。确切的大小根据系统中有多少节点和多少数据库而异。尽管预计orachk有时会像在“什么时候运行ORAchk”章节中描述的，随着时间的推移，文件的数量堆积，而客户可能想要执行维护并清理旧文件和/或子目录。

每个客户可能有不同的要求，因此客户有责任来定义执行自己战略的流程，以维护这些子目录和文件。有些客户可能选择将文件归档到不同的系统。有些客户可能需要删除子目录并保存.zip文件。还有一些客户可能会选择同时删除旧的子目录和.zip文件

Oracle建议客户执行cron作业或其它调度工具（例如，Oracle企业管理器）来根据个人的需要执行这个任务的过程和程序。

附录 K –最高可用性结构记分卡 (MAA)

MMA计分卡是一组最高可用性架构的最佳实践和与它们相关的调查结果。其目的是提供客户一个记分卡为他们准备好各种在Oracle数据库环境中的可能发生的故障。现在MAA记分卡默认显示在orachk中，因为MAA被认为是一个非常重要的概念和功能。不过，有些客户可能没有实施Oracle Data Guard，实施了Oracle Data Guard备用数据库才能让MAA发挥最大功能，但即使Oracle Data Guard没有被实施，建议以MAA记分卡运行orachk。如果在分析中包含MAA记分卡是不理想的，通过运行orachk使用-m参数来压缩它，例如。

附录 L – 为11.2.0.3及以上版本升级准备检查

有许多文档讨论了升级到Oracle RAC版本11.2.0.3-升级配套，升级指南，Oracle数据库文件，手动升级清单等等各方面。工具的升级准备模块将许多东西的检查例如最佳实践，补丁的前提条件，配置的前提条件等等自动化。其目的是简化和增强升级过程的可靠性。虽然我们试图覆盖尽可能多的点，但仍然建议客户查看升级文件，因为一些概念或单个项目不轻易让本身自动化。参见运行升级准备检查的语法的使用章节。

附录 M – 配置ORAchk的SUDO权限

In order to take advantage of the full functionality of ORAchk, root access is required to run the root specific checks. To facilitate these checks in silent mode we MUST configure passwordless SUDO and utilize the -s (more on this later) option to execute ORAchk. Configuring SUDO will also allow for parallel ORAchk execution (new in 2.2.1) without having the EXPECT utility installed on the system.sudo configuration is not required if orachk deamon is configured with or without auto restarting daemon feature using init. To configure SUDO add the following line to the sudoers file on each of the cluster nodes using visudo command replacing “<oracle>” with the appropriate RDBMS software owner: 为了利用ORAchk的全部功能，需要root权限来运行root专项检查。为了便于在静默模式下执行这些检查，我们必须配置无密码SUDO并使用-s（之后会讲到更多）选项来执行ORAchk。配置SUDO也将允许并行ORAchk执行（2.2.1版本新功能），而无需Expect的工具安装在system.sudo，如果orachk守护程序使用init被配置带或不带自动重启守护进程的功能，配置是不是必需的。要配置SUDO，用visudo命令以相应的RDBMS软件所有者替换“<oracle>” 将以下行添加到每个集群节点的sudoers文件：

附录 N –平台明智的检查需要root权限

了解需要root权限的平台的完整检查列表，请参阅ORAchkPlatform wiseChecksthatRequireRoot.pdf， Note: 1268927.1.

附录 O – 升级 ORAchk

ORAchk的新版本将定期发布。经常检查MOSNote: 1268927.1 新版本和/或订阅ORAchk MOS社区获得最新资讯。

从 2.2.5版本升级ORAchk：

注: 2.2.5之前的版本需要手动升级（重命名旧目录，并创建新的目录）

从MOS Note: 1268927.1 下载ORAchk的新版本到共享的网络临时目录（不要解压）
设置环境变量$ RAT_UPGRADE_LOC到临时目录
执行“orachk-upgrade”升级ORAchk

要升级ORAchk 12.1.0.2.1及以上的版本：

在ORAchk 12.1.0.2.1中，默认下，当ORAchk启动时，如果指定的话，它会寻找$ ORACLE_HOME / suptools或$ RAT_UPGRADE_LOC中的新版本。如果有新的版本存在，ORAchk将自动升级到新版本。最好的做法是将orachk.zip暂存到能被运行ORAchk的所有环境访问的网络共享中，并将环境变量

$ RAT_UPGRADE_LOC设置到该位置。

注: 要绕过自动升级，你可以执行“orachk -noupgrade”。如果ORAchk的版本在120天之前-noupgrade选项将不会生效。

从MOS Note: 1268927.1 下载ORAchk的新版本到共享的网络临时目录（不要解压）
设置环境变量$ RAT_UPGRADE_LOC到临时目录
执行 ORAchk，执行时 ORAchk 会提示确认升级

要升级ORAchk 12.1.0.2.4及以上的版本：

当ORAchk版本在120天之前，且新版本本地不可用，ORAchk会自动连接到My Oracle Support（假定网络是可用的），下载并升级ORAchk。MOS的下载可以手动触发“./orachk–download”。

附录 P – Windows Cygwin 要求

Cygwin本质上是为Microsoft Windows主机提供类似Linux环境的工具。从技术上讲，它是一个DLL（cygwin1.dll），作为一个提供大量的Linux API功能的Linux API层。

为了使客户能够在Windows环境下使用ORAchk，Oracle建议在数据库服务器上安装Cygwin。 Cygwin提供与ORAchk兼容的bash脚本shell环境。一旦安装了Cygwin，你可以在主机上配置SSH服务且只有在Oracle RAC安装时需要SSH服务。

有关如何安装Cygwin供ORAchk使用的完整说明，请参阅MOS Note: 1268927.1 中的“支持的环境”选项卡以及向下搜索Windows支持。

附录 Q –身份管理支持

详见 – IAM Healthcheck tool using ORAchk. 以及 MOS Note: 1268927.1

附录 R – 用户定义的检查

在12.1.0.2.5版本中， ORAchk现在支持用户自定义检查。这些是客户根据具体环境编写，测试，验证和维护的检查。Oracle将支持这些用户定义检查的创建和运行框架，但不支持检查本身的逻辑。测试，验证，编写，维护和支持检查都是由客户来完成。该检查将在运行时由ORAchk脚本执行，且用户定义检查的结果将显示在HTML报告的用户定义检查部分。

ORAchk提供了特殊的内置配置文件，称为user_defined_checks，它可以在运行时作为命令行参数限制在那些用户定义检查的检查范围。使用内置的信息是测试用户定义检查的有效方法，因为只有客户的检查将被运行，这将加快了进程。

用户定义检查被存储在ORAchk集合管理器schema中，输出到之后与ORAchk脚本共同所属的XML文件。当ORAchk 12.1.0.2.5及以上在客户的系统上运行时，它会检查该XML文件名称是否存在，如果找到一个，默认下它会运行其中包含的检查，包括在标准HTML报告中的结果。如果在命令行中指定了user_defined_checks配置文件，那么只有包含在XML文件中的用户定义检查将被执行。

Oracle在用户定义检查选项卡下ORAchk集合管理器应用中提供了编写环境。基本概念是，用户在该环境中定义检查，当准备好时生成XML文件。所有已被编写的检查且未被搁置的检查在生成时将被包含在XML文件中。搁置检查相当于一个“逻辑删除”。如果检查时发现问题或逻辑尚未完善，就可以搁置它，以保持其不被包含在XML文件，直到它为生产环境作好了准备，那么搁置可以被移除，在下一次它被生成时包括在XML文件中。

支持操作系统和SQL命令。不支持以root运行用户自定义检查。在编写页中，可以点击每个字段标签以得到说明该字段使用的帮助文本。一个星号表示字段需要输入。根据检查的上下文的所有情况中，有一些字段是不需要的。比如，许多操作系统命令可能对数据库的相关信息没有任何依赖性。在这些情况下，如果是为了编写检查，字段可以被忽略。

If installing ORAchk Collection Manager is not an option the user defined checks can still be created and run using the sample user defined checks XML file provided with the distribution however this requires hand-editing an XML file which could be error prone and difficult to debug. For that reason it is highly recommended that if it would be useful for the customer to be able to include user defined checks that they use the ORAchk Collection Manager interface to do so. 如果不能安装ORAchk集合管理器，使用XML文件在发行版提供的示例用户定义检查，用户定义检查仍然可以被创建和运行。但这需要手动编辑XML文件，可能容易出错且难以调试。出于这个原因，强烈建议如果客户将能够包括用户定义的检查，那么他们使用ORAchk集合管理器界面是有用的。

运行时的用户定义检查

如果user_defined_checks.xml文件与orachk脚本在同一位置，那么默认下在XML文件中的用户定义检查将运行，且其结果将显示在题User Defined Checks的部分。在这种情况下，不需要特殊的参数或选项。

另外，如果仅运行完成的用户定义检查，在命令行使用user_defined_checks内置配置文件作为参数。当使用了此选项时，用户定义检查将是唯一的检查运行且User Defined Checks部分将是唯一在报告中有显示结果的。

./orachk –profile user_defined_checks

要省略运行时的用户定义检查，使用–excludeprofile参数来实现

./orachk –excludeprofile user_defined_checks

以下部分描述了用户定义检查的元素，这些包含在编辑工具中。它们与组成ORAchk内置检查的元素相同。

检查名称:

使用一个自我记录的名称，并尽可能简洁，以确定检查的目的。

版本:

列出的版本支持Grid Infrastructure和数据库。如果你的检查适用于多个支持的版本，则使用shuttle widget将它们包括在内。即，将其移动到右侧窗格中。你的检查将只在特定版本或指定的版本运行，有时检查的逻辑可以是版本特定的。在这些情况下，仅包括特定版本。指定不在你的环境中存在的版本不会造成任何损坏。不在你的环境中存在的版本只会被忽略。另一方面，如果检查是特定版本的话，你最好删除检查不适用的版本。

平台:

The listed platforms are supported for Grid Infrastructure and Database. If your check applies to multiple supported platforms then include them using the shuttle widget, ie., move them to the right pane. Your checks will only run for the platform or platforms that you specify and sometimes the logic for a check can be platform-specific. In those cases only include the specific platform. It doesn’t hurt anything to specify platforms that do not exist in your environment.

Platforms that do not exist in your environment will just be ignored. On the other hand, if a check is platform-specific then you would want to remove the platforms that the check does not apply to. 列出的平台支持Grid Infrastructure和数据库。如果你的检查适用于多个支持的版本，则使用shuttle widget将它们包括在内。即，将其移动到右侧窗格中。你的检查将只在特定版本或指定的版本运行，有时检查的逻辑可以是版本特定的。在这些情况下，仅包括特定版本。指定不在你的环境中存在的版本不会造成任何损坏。不在你的环境中存在的版本只会被忽略。另一方面，如果检查是特定版本的话，你最好删除检查不适用的版本。

Linux OELRHEL 指 Oracle Linux 或 Red Hat Linux

命令:

OS commands or inline programs and SQL commands should result in a single string or numeric return value that can be compared to a single comparison value using an appropriate string or numeric comparison operator. Typically this will be a boolean return value e.g.., 1 or 0. But it could be a count resulting from the use of a command like grep -c or select count(*) where the count is expected to be 0 or a non-zero number depending upon the logic required for your check. The important thing to remember though is that it should not result in a list or array. OS命令或内嵌程序和SQL命令应导致一个字符串或数值返回可与使用适当的字符串或数字比较操作符的单一比较值相比较。通常这会是一个布尔返回值，例如，1或0，但它可能是根据你的检查需要的逻辑，对预期是0或非零的计数使用如grep-c或select count(*)得到的计数。但重要的是，不应该得到列表或数组。

The best approach is to perfect your logic in a terminal shell or sqlplus and once perfected copy and paste it into the Command field of your check. Note that ORAchk populates two environment variables at runtime $CRS_HOME and

$ORACLE_HOME. So you can use those in your logic. $CRS_HOME will be static but $ORACLE_HOME will change according to the context of its usage for databases. 最好的办法就是在终端shell或sqlplus中完善你的逻辑，一旦被完善，将它复制并粘贴到你的检查的命令字段。注意ORAchk在运行时填充两个环境变量，$ CRS_HOME和 $ ORACLE_HOME。所以你可以在你的逻辑中使用那些。 $ CRS_HOME将是静态的，但$ ORACLE_HOME将根据其对数据库用途的情况而变化。

Note that when querying v$ views in Oracle using OS commands the dollar sign needs to be escaped as in v\$parameter.

Note also that it is possible to embed SQLPlus formatting directives in your command and that a newline character (\n) follows them. NOTE: DO NOT embed any tabs in multi-line programs as that may cause problems parsing or executing the commands. 注意当使用OS命令查询在Oracle查询v$ views时，美元符号需要被转义为v\$参数。

另外注意，可以在你的命令中嵌的SQLPlus格式化指令，后跟一个换行符（\ n）。注意：不要在多行程序中嵌入任何标签，因为这可能导致问题解析或执行命令。

下面是一个OS命令的例子：

afdest=$(echo -e “set heading off timing off feedback off lines 180\n select value from v\$parameter where name=’audit_file_dest’;”|$ORACLE_HOME/bin/sqlplus – s / as sysdba|grep -v ^$)

aud_files=$(find $afdest -name ‘*.*’ 2>/dev/null|wc -l) if [ $aud_files -gt 100000 ]

then echo 1

else echo 0 fi

注: SQL 命令应有一个终止分号。

Sample OS Check Commands:

注意此命令中嵌入了一个SQL命令，它被管道传送到sqlplus中。

afdest=$(echo -e “set heading off timing off feedback off lines 180\n select value from v\$parameter where name=’audit_file_dest’;”|$ORACLE_HOME/bin/sqlplus -s / as sysdba|grep -v ^$)

aud_files=$(find $afdest -name ‘*.*’ 2>/dev/null|wc -l) if [ $aud_files -gt 100000 ]

then echo 1

else echo 0 fi

ps -ef|grep -v grep|grep -c OSWatcher.sh

interval=$(ps -ef|grep -v grep|grep OSWatcher.sh|head -1|awk ‘{print

$10}’)

if [[ $interval -ge 30 && $interval -le 60 ]] then echo 1

else echo 0 fi

示例SQL命令

注意终止的分号。

select count(ts.segment_space_management) from dba_tables t, dba_tablespaces ts where ts.tablespace_name = t.tablespace_name and t.table_name in (‘AUD$’,’FGA_LOG$’) and upper(ts.segment_space_management) != upper(‘AUTO’);

select ‘force_logging_mode_enabled = ‘||force_logging from v$database;

报告命令:

报告命令是一个OS或SQL命令，它会得到格式化输出，易于审查报告的用户的阅读，且输出会便于用户验证它伴随的检查的结果。因此它会从运行时的系统得到格式化输出，与检查逻辑本身可包含多行数据的列表不同。

另一方面，你不希望打印出几百或几千的文本行。这将难以阅读并使报告的尺寸比必要的大出很多。

So in the report command example the number of audit files is output in a very readable and understandable format rather than listing of all the audit files and the user can clearly see if ether are more audit files than should be allowed to build up on the filesystem and there is action required to remediate the problem. Limit your output to a reasonable number of rows. If necessary refer users to a command they can run manually to derive the complete set of data needed for Action / Repair. 因此，在报告命令示例中，审计文件的数量是以非常易于阅读和理解的格式输出，而不是所有审计文件的列表。用户可以清楚地看到是否更多的审计文件应该被允许在文件系统中建立，而且还有修复问题所需的操作。将你的输出限制到合理的行数。如果有必要，让用户参考可以手动运行的命令，以获取行动/修复所需的完整数据。

在ORACHK外测试你的逻辑，在将命令粘贴到这里之前验证格式。

示例报告命令：

echo -e “Number of audit files at $afdest = $aud_files”

示例 OS 报告命令:

注意此命令使用存储在上述OS命令中的输出变量。

echo -e “Number of audit files at $afdest = $aud_files” ps -ef|grep -v grep|grep OSWatcher.sh

echo -e OSW interval = $interval seconds

示例SQL报告命令:

注意终止分号。

select t.table_name,ts.segment_space_management from dba_tables t, dba_tablespaces ts where ts.tablespace_name = t.tablespace_name and t.table_name in (‘AUD$’,’FGA_LOG$’);

select ‘Database force logging mode = ‘||force_logging from v$database;

比较运算符:

The comparison operator is used in conjunction with the command’s actual return value and the comparison value, which is the expected return value. The comparison is evaluated and the check either passes or it fails. Valid comparison operators and their type, numeric or string, are listed in the Comparison Operator shuttle widget. 比较运算符与命令的实际返回值和比较值结合使用，这是预期的返回值。比较被评估，检查或者通过或者失败。有效的比较运算符和它们的类型，数值或字符串，列在比较运算符shuttle widget中。

比较值:

比较值是与比较运算符和实际的命令返回值结合使用来确定PASS/ FAIL的预期返回值。换句话说，如果预期与实际的返回值不同，这会导致警告或故障。如果都相同，一个pass会是结果。

候选系统：

如果ORAchk正在运行的系统是一个RAC或非RAC数据库系统，那么数据库或Grid Infrastructure checks检查可以被运行。然而，一些检查对于RAC系统是特定的，而其他可能只适用于非RAC系统。在许多情况下，一个检查可能同时适用于这两各。使用shuttle widget指定检查适用于RAC还是非RAC或两者都适用。

组件依赖性：

如果检查命令的成功运行需要的话，选择一个Oracle stack的组件。例如，如果一个检查命令在查询ASM实例，那么ASM实例必须运行起来才能成功被查询。如果不是，那么检查逻辑依赖的sqlplus命令会丢失一些输入。如果运行时没有满足组件依赖性，那么检查将被跳过。

如果在运行时不需要组件依赖性，则不需要进行选择。

数据库模式：

如果正在运行的命令包含一个依赖数据库模式以获取所需数据的SQL命令，那么在这里选择合适的模式 – nomount, mount, open。对数据库执行的大部分，但并非全部SQL命令将取决于Open模式运行的数据库。

如果在检查中没有数据库依赖性，则不需要进行选择。

数据库类型：

Database versions BEFORE 12.1 are referred to here as NORMAL (not multi- tenant). Database versions 12.1 or greater could be NORMAL (not multi-tenant),

CDB (multi-tenant container DB), or PDB (multi-tenant pluggable DB). Select the appropriate Database Type(s) for your check depending upon version and multi-tenancy. Your check will only run on the specified Database Type(s). 12.1之前的数据库版本在这里称为NORMAL（不是多租户）。数据库版本12.1或更高版本可以是NORMAL（不是多租户），CDB（多租户容器DB），或PDB（多租户可插拔DB）。根据版本和多租户技术为你的检查选择适当的（多个）数据库类型。你的检查只会在指定的数据库类型（S）运行。

如果完全没有数据库依赖性，那么不需要选择。

数据库角色：

数据库角色有PRIMARY, 物理 STANDBY, 逻辑 STANDBY。物理备用数据库可能在管理恢复（安装模式）或只读模式下运行，所以可运行的SQL检查可能不同。

同样的逻辑备用数据库可能在应用模式下运行，所以可运行的SQL检查可能不同。在数据库整合环境中，在给定的系统上可能有各种角色的数据库。角色是在运行时为每个数据库决定的。 ORAchk / EXAchk对适当的角色运行检查，而对不恰当的角色忽略检查。

如果完全没有数据库依赖性，那么不需要选择。

Oracle Home 类型：

Oracle Home类型控制在运行时的ORACLE_HOME环境变量的设置，例如在一个Oracle可执行文件需要从home运行的情况。可能从home运行的可执行文件的例子是sqlplus，srvctl, crsctl, oifcfg等。一般来说，如果你的逻辑使用Oracle可执行文件来获得数据，那么脚本需要知道从哪个home的bin目录中找到可执行文件。shuttle widget列出了有效的选择。

If your check logic has no dependencies on Oracle executables, i.e. just basic OS commands, then no selection is required. 如果你的检查逻辑对Oracle可执行文件没有依赖性，即只有基本的OS命令，则不需要选择。

警报级别:

从有效值的列表中选出警报级别。这些警报级别是有些主观的，但一般FAIL应留给潜在的最严重问题，而WARNING是严重的但没有上升到FAIL的水平。INFO是最不严重的，但评估和更正仍是重要的。

通过赋予INFO的警报级别并设计一个会失败的检查使纯粹的信息数据传递到报告也是可以的，即..，无操作检查。

注:通过的INFO不显示在报告中，因此一个INFO检查失败可以用来在报告中显示所需的信息。

通过信息:

如果你的检查通过了，这是你想要在报告中显示的文本。它应当限制在80 – 100个字符。它不是要发出冗长的消息，只是对发现结果的摘要。

失败信息:

如果你的检查没有通过，这是你想要在报告中显示的文本。它应当限制在80 – 100个字符。它不是要发出冗长的消息，只是对发现结果的摘要。

效果/影响：

The Benefit/Impact, Risk and Action/Repair together comprise the Rationale for the recommendation – why it is important (Benefit/Impact), what might happen if mis-configured (Risk), and how to mitigate the risk (Action/Repair). The three fields are concatenated together at runtime to form the entire rationale. 效果/影响，风险和行为/修复共同构成推荐的理由 – 为什么它是重要的（效果/影响），如果配置错误会发生什么（风险），以及如何降低风险（行为/修复）。这三个方面在运行时结合，构成完整的理由。

效果/影响顾名思义解释了推荐的原因，以及它会如何影响系统。

风险:

Risk should explain what the negative impact might be if the recommendation is not followed. Examples are sub-optimal performance, instability, reduced availability, etc. 风险解释了如果不遵守建议，负面影响可能是什么。示例是次优性能，不稳定性，和降低的可用性等。

行为/修复:

Action/Repair should communicate how to deal with the problem if found to exist. This could be as simple as instructions about how to remediate or it could tell the user to reference an more comprehensive document in the References section. In that case it is better just to say “Please see the referenced documents for more details.” Then the references from the References section will appear immediately below in the report. Review an ORAchk report with built-in checks to see how these sections are displayed in the reports and take your queues from the weay those are formatted to better understand how your messaging will be transferred to the report. 行为/修复传达了如果发现问题，如何进行处理。这可以像如何修复的教程一样简单，或者可以告诉用户参考在参考部分的一个更全面的文档。在这种情况下，最好就说“请查看参考文档获取更多细节。”然后，参考部分的引用都将立即出现在报告中的正下方。用内置检查复核ORAchk报告，以查看这些部分是如何显示在报告中的，并把你的队列从weay那些被格式化到更好地了解你的信息是如何转变为报告。

参考：

You can specify references that back up or further explain the rationale or that explain in more detail the Action / Repair. These references can be MOS Notes, external product documentation websites, or even customer authored reference documents not otherwise accessible to other Oracle customers, eg., customer build or standards documents. These references will be converted to clickable HTML links. 你可以指定参考来验证或进一步解释理由或者指定它更详细地解释行为/修复。这些参考可以是MOS笔记，外部产品文档的网站，甚至是客户撰写的参考文件，由其他Oracle客户无法访问，例如，客户构建或标准文档。这些参考文献将被转换为可点击的HTML链接。

For MOS Notes enter the note number and title. For other references enter the document title and URL. As references are added hey will be listed in the left panel of the shuttle widget and can be selected again later if applicable to other checks. If new references are added they will be applied to the current check, appear in the right shuttle pane for the current check, and also be added to the list of available references for future selection as appropriate. 对于MOS笔记，输入笔记号和标题。对于其他参考文献，输入文档标题和URL。当添加了文档，它们会被列在shuttle widget的左侧面板中，如果适用于其他检查，可以之后被选择。如果新的参考被添加，它们将被应用于当前检查，出现在右梭窗格用于当前检查，同时被添加到可用参考的列表，适当时用于之后的选择。

附录 S – 应用连续性支持

在版本12.1.0.2.5中，对应用连续性的支持被添加。

为Oracle具体类控制AC检查（在orachk称为acchk）的有三个值。它们可以在命令行或通过shell环境变量（或混合）设置。有以下几种。

命令行参数	Shell 环境变量	使用
–asmhome jarfilename	RAT_AC_ASMJAR	这必须指向asm-all-5.0.3.jar的一个版本，从http://asm.ow2.org/下载。
-javahome JDK8dirname	RAT_JAVA_HOME	这必须指向JDK8安装的JAVA_HOME 目录。
-appjar dirname	RAT_AC_JARDIR	为了分析引用Oracle具体类的应用代码，如oracle.sql.BLOB，这必须指向代码的th父目录名称。该计划将analy.class文件，并递归地.jar文件和目录。如果J2EE .ear或.war文件，你必须用外露的.class文件递归地显示这些目录结构。该测试适用于为Oracle 11或12编译的软件类。

当你运行AC检查时，对数据库服务器的额外检查等被关闭。在中间层运行具体类检查来分析访问Oracle驱动程序的软件是很常见的。

详见文章 – Using Orachk to Clean Up Concrete Classes for Application Continuity

附录 T – ZFS 存储应用支持

在版本 12.1.0.2.5 中，ZFSSA支持已经扩展到非工程体系。在支持的附带ZFSSA存储的客户端系统运行orachk，使用以下语法

./orachk -zfssa node1,node2

版本新功能

版本 12.1.0.2.5

创建你自己的检查
Would you find it useful to easily run your own environment or business specific checks? 你是否发现它对轻松运行你自己的环境或业务特定检查很有用？
使用ORAchk对自己的自定义用户定义检查进行编写，执行和报告。
使用集合管理器界面来编写你的检查。
使用ORAchk内置的电子邮件通知和差异报告
在ORAchk html报告中的“用户自定义检查”部分查看检查结果
使用ORAchk集合管理，收集并简易查看企业范围的所有结果

扩展的Oracle产品支持
ORAchk 12.1.0.2.5 进一步扩展Oracle 产品栈的支持，通过以下新支持的Oracle产品：
- Oracle身份管理器
- Oracle电子商务套件客户关系管理
- Oracle电子商务套件项目开票
- Oracle ZFS存储设备
- Oracle虚拟网络
- OraclePeopleSoft应用程序
- 应用连续性

轻松运行或排除特定独立支票

新的命令行开关已添加，所以你可以很容易地排除或只运行特定检查

缩短ORAchk执行时间
ORAchk现在有缓存发现的数据库的功能，这意味着数据库重新发现被忽略且执行时间更快。如果数据库更改，你可以简单地发出一个命令使ORAchk刷新缓存。

支持自定义EBS APPS用户

ORAchk现在将动态确定Apps用户，启用的所有EBS检查以供使用，即使你已经改变了Apps用户的名称。

超过100个新健康检查
ORAchk的新版本带来了超过100个新的检查，在以下领域包含了一些Oracle客户支持已知的最具影响力的问题：
补丁，性能，可扩展性和高可用性的数据库的最佳实践
Oracle身份管理预安装设置，安装后的配置和运行时环境
人力资源和CRM（预测，支付表和服务合同）的电子商务套件最佳实践配置设置
对项目开票中不兼容的配置电子商务套件的早期侦测
对性能和弹性的Oracle ZFS存储应用的最佳实践配置
Oracle虚拟网络的最佳实践配置设置
PeopleSoft应用的数据库的最佳实践

版本 12.1.0.2.4

当新版本时可用自动更新ORAchk
当ORAchk未更新超过120天，较新的版本在本地不可用，它会查看在My Oracle Support是否有较新的版本可用并自动下载和升级。
从My Oracle Support直接下载最新版本可以专门由“./orachk-download”触发。
当在守护进程模式运行时，ORAchk会从下一个计划运行前，从由RAT_UPGRADE_LOC定义的本地位置进行自动升级时，电子邮件将发送升级通知。
ORAchk12.1.0.2.4现在给整个Oracle产品栈带来更广泛和更深入的支持，对下列产品领域有新增的支持：
企业管理OMS
电子商务套件的Oracle固定资产
电子商务套件Oracle人力资源
电子商务套件Oracle应收款
Siebel CRM应用
超过60个新的健康检查
Bug 修复

版本 12.1.0.2.3

System Z (RHEL 6, RHEL 7, Suse 12)上的 Linux
Oracle企业级Linux7
单实例ASM检查
升级12.1.0.2的验证检查
增强的金门检查
企业管理器代理检查
增强的报告，突出了ORAchk无法获得完整可见性的检查（需要手动验证的检查）

改进的健康评分计算（现在可以达到100％）
超过50个新的健康检查
Bug修复

版本 12.1.0.2.1

Windows 支持 (需要Cygwin，查看附录 O 中 Cygwin 要求)
支持作为“root”的执行，以简化角色分离环境中的执行
将基准比较扩展到集合
使用标签装用户定义的集合名称的功能
从单一的共享位置自我升级
对单实例环境启用ASM检查
新的检查和bug修复

版本 2.2.5

对多个数据库并行执行检查
允许通过ORAchk守护进程的多次运行
Move away from /tmp as temporary destination, $HOME directory is the new temporary destination (allowed to be overridden by setting RAT_TMPDIR) 从/ tmp作为临时目的地移动，$ HOME目录是新的临时目的地（可以通过设置RAT_TMPDIR覆盖）
对健康检查分数计算包括跳过的检查的增强
对集群范围的检查增强的报告
ORAchk 现在通过新的”-upgrade” 选项升级
Granular help at the command line option level, for example在命令行选项级别的细粒度帮助，例如：./orachk –profile –h
对预安装检查的新配置文件
单实例升级前/后的最佳实践（升级准备）
集合管理器现在已经与ORAchk (CollectionManager_App.sql)被捆绑
新的检查和 bug 修复，包括

o o o

版本 2.2.4

数据库层的企业云控制最佳实践

超过40个对Oracle栈的新的健康检查

对电子商务套件的工作流程和Oracle采购的其他产品领域的扩展

节点重启（init集成）后ORAchk守护进程自动启动模式
合并多个ORAchk集合报告
根据配置文件排除检查
安装的数据库补丁的上传
ORAchk，RACcheck和Exachk 的集合管理器
所有节点上的/ tmp中ORAchk签名文件以验证最后的ORAchk运行
新的检查和bug修复，其中包括

o o o

版本 2.2.3

30 个Oracle 电子商务 AP模块升级完整性检查

12 个新的数据库检查

8 个新的Solaris系统检查

的最佳实践检查（只适用于运行GoldenGate的数据库）
记分卡中数据库整合最佳实践

ORAchk 守护进程增强功能，允许除了间隔选项外在特定的日期/时间执行enhancement allowing for execution at specific scheduled dates/times in addition to interval option

如果发现差异，ORAchk守护差异检查的 current 和current-1 报告并邮件通知
基于检查名称排除检查的功能
排除的检查列在HTML报告中
可视化进展的指标被添加以确认在关键点的脚本进展
新的检查和bug修复

版本 2.2.2

现在可以作为root用户执行系统管理员配置文件，例如， ./orachk-profile sysadmin
在预定的时间段非交互式自动执行ORAchk 的ORAchk守护进程功能
支持Solaris Sparc 11
升级11.2.0.3，11.2.0.4（尚未发布）和12c（尚未发布）的最佳实践
ORAchk输出目录重组
标准健康检查现在包括在升级后
新的检查和bug修复

版本 2.2.1

在所有节点并行的执行（对于root检查，需要OS预期工具或SUDO来启用此功能）
使用配置文件来执行检查的子集，例如： DBA，Sysadmin，ASM
比较两个ORAchk的功能
新的检查和bug修复

版本 2.2.0

单实例数据库支持（包括Oracle重启）
高可用性检查
RAC单个节点支持
添加到数据库报告表以提高灵活性（见附录F）的附加列
新的检查和bug修复

版本 2.1.6

新支持的平台：
OEL 和 RHEL 6
HP-UX (需要BASH shell 3.2 或更高)
AIX 7 (需要BASH shell 3.2 或更高)
HTML 报告 ADA 合规
新的检查和bug修复

版本 2.1.5

升级准备检查 (11.2.0.3 目标版本及以上)
MAA 记分卡现在默认显示 (使用 -m 参数来压缩)
Bug修复和其他一般改进

版本 2.1.4

远程数据库支持。orachk将对在除了工具执行节点的节点上运行的数据库实例检查数据库最佳实践
Solaris x86-64支持
提升多个数据库版本的支持的加强
新的检查和bug修复

版本 2.1.3

11.2.0.3 支持
Suse 11 支持
MAA 记分卡
Bug 修复

版本 2.1.2

新的基于 HTML的报告

· Bug 修复

ORAchk 用户使用手册 orachk Oracle配置审计工具

运行ORAchk指南

如何交互运行 ORAchk

ORAchk守护模式操作

使用配置文件运行检查的子集

用ORAchk执行报告比较

合并ORAchk报告

在升级准备模式下运行ORAchk

其他有用的选项

附录A – 故障排除

附录 B – 如何获取支持

附录 C – 运行ORAchk应该要多久

附录 D – 由ORAchk处理密码

“-debug” 选项和密码

检查名称:

版本:

平台:

命令:

报告命令:

比较运算符:

比较值:

候选系统：

组件依赖性：

数据库模式：

数据库类型：

数据库角色：

Oracle Home 类型：

警报级别:

通过信息:

失败信息:

效果/影响：

风险:

行为/修复:

参考：

Comment 取消回复