原文链接： http://www.dbaleet.org/what_is_dcli/
在上篇文章中， 介绍group文件的用途的时候曾经提到过一个叫做dcli的工具，但也只是一笔带过，这篇文章主要介绍dcli的用途及用法。
随着云计算的越来越盛行，未来可预见集群的规模会变得越来越大， 而在大型的数据中心，一个系统管理员/数据库管理员有可能同时需要管理几十上百的主机。例如要进行一些常规性的维护或者配置工作，如果还使用原始的方式进行管理，这几乎是碟中谍（Mission Impossible）了。
科技的发展从来都是靠聪明的懒人来驱动的，人类不想打猎，于是就学会了驯养家畜；不想采摘，于是发明了种植；不想洗衣服，于是发明了洗衣机。不想步行，于是发明了机动车等等。虽然这个过程所付出的艰辛往往不是外人三言两语能说清道明的。当然“要有光， 于是便有了光”那就只能靠神明的力量了。同样，集群节点的成倍增长， 配置管理系统的诞生便是一件理所当然的事情了。
很多有经验的系统管理员一定听过其中大名鼎鼎的Puppet ， 这个工具非常强大，并且现在被广泛的应用在各大型的IT企业，例如Dell， Twitter, Oracle, Citrix, Google, Wikipedia等。例如Google就曾经用它来管理几千台Mac桌面电脑。今天提到的DCLI(全称分布式命令行 Distributed command line interface)也是类似的工具，不过远比puppet简单，无需系统的学习就能迅速的掌握。Exadata的节点数众多，要是纯粹通过手工来管理则过于繁琐，并且无法达到整齐划一的配置，而如果使用Puppet这样的神器又给人以用牛刀杀鸡的感觉。
来看一下DCLI有多简单, 以下是一台半配的Exadata用来获取各节点的系统时间：
[root@dm01db01 ~]# /usr/local/bin/dcli -g /opt/oracle.SupportTools/onecommand/all_group -l root "date" dm01db01: Sat Jun 2 16:59:47 CST 2012 dm01db02: Sat Jun 2 16:58:32 CST 2012 dm01db03: Sat Jun 2 17:00:00 CST 2012 dm01db04: Sat Jun 2 17:05:11 CST 2012 dm01cel01: Sat Jun 2 16:59:48 CST 2012 dm01cel02: Sat Jun 2 17:04:43 CST 2012 dm01cel03: Sat Jun 2 17:03:08 CST 2012 dm01cel04: Sat Jun 2 17:04:29 CST 2012 dm01cel05: Sat Jun 2 17:04:23 CST 2012 dm01cel06: Sat Jun 2 17:00:31 CST 2012 dm01cel07: Sat Jun 2 17:04:11 CST 2012
但是执行这个命令却有一些简单的前提条件：
1. 需要预先配置各节点用户等效性，例如这里使用root用户执行，那么所有节点root用户都需要配置ssh用户等效性。
2. 需要存在一个group文件，例如在上面这条指令中就是/opt/oracle.SupportTools/onecommand/all_group， 这个文件中保存了需要执行这条命令节点的主机名或者ip地址。当然前面也提到过，这些文件可以由dbm configurator或者exaconf自动生成。
3. 需要安装dcli这个工具。在Exadata， Exalogic， Exalytics系统都自带这个工具。但是这个工具并不局限于用于Oracle的这些工程机系统，拷贝到其它Linux上就能直接使用。
下面再来简单的看下这个工具的构成：
[root@dm01db01 ~]# file /usr/local/bin/dcli /usr/local/bin/dcli: a python script text executable
可以看到这个文件其实就是一个python脚本。然后打开这个文本文件，里面就提到了一些简单的用法以及其依赖关系——需要安装python 2.3以上的运行环境。
再来看一下其帮助的语法：
[root@dm01db01 ~]# dcli -h
Distributed Shell for Oracle Storage
This script executes commands on multiple cells in parallel threads.
The cells are referenced by their domain name or ip address.
Local files can be copied to cells and executed on cells.
This tool does not support interactive sessions with host applications.
Use of this tool assumes ssh is running on local host and cells.
The -k option should be used initially to perform key exchange with
cells. User may be prompted to acknowledge cell authenticity, and
may be prompted for the remote user password. This -k step is serialized
to prevent overlayed prompts. After -k option is used once, then
subsequent commands to the same cells do not require -k and will not require
passwords for that user from the host.
Command output (stdout and stderr) is collected and displayed after the
copy and command execution has finished on all cells.
Options allow this command output to be abbreviated.
Return values:
0 -- file or command was copied and executed successfully on all cells
1 -- one or more cells could not be reached or remote execution
returned non-zero status.
2 -- An error prevented any command execution
Examples:
dcli -g mycells -k
dcli -c stsd2s2,stsd2s3 vmstat
dcli -g mycells cellcli -e alter iormplan active
dcli -g mycells -x reConfig.scl
usage: dcli [options] [command]
options:
--version show program's version number and exit
-c CELLS comma-separated list of cells
-d DESTFILE destination directory or file
-f FILE file to be copied
-g GROUPFILE file containing list of cells
-h, --help show help message and exit
-k push ssh key to cell's authorized_keys file
-l USERID user to login as on remote cells (default: celladmin)
-n abbreviate non-error output
-r REGEXP abbreviate output lines matching a regular expression
-s SSHOPTIONS string of options passed through to ssh
--scp=SCPOPTIONS string of options passed through to scp if different
from sshoptions
-t list target cells
-v print extra messages to stdout
--vmstat=VMSTATOPS vmstat command options
-x EXECFILE file to be copied and executed
常用到的选项有-g -l -x -r几个选项。-g后面解的是group文件， -l跟执行的用户， -x表示执行这个文本文件； -r表示使用正则表达式排除某个关键字。
以下简单举几个例子说明:
1. 查看所有DB节点数据库的PSU版本：
[root@dm01db01 ~]# dcli -g /opt/oracle.SupportTools/onecommand/all_group -l oracle \ "/u01/app/oracle/11.2.0.3/dbhome_1/Opatch/opatch lsinventory -bugs_fixed | grep -i 'DATABASE PSU' ”
2. 查看所有cell节点的不属于RECO磁盘组的grid disk:
[root@dm01db01 ~]# dcli -g /opt/oracle.SupportTools/onecommand/cell_group -l root -r "reco" "cellcli -e list griddisk"
3. 部署一个脚本/usr/local/monitoring/script.sh到所有的DB节点执行：
[root@dm01db01 ~]# dcli -g /opt/oracle.SupportTools/onecommand/dbs_group -l root-x /usr/local/monitoring/script.sh
4. 使用vmstat查看所有cell节点的内存使用状况，采样频率为5秒一次，一共采样5次：
[root@dm01db01 ~]# dcli -g /opt/oracle.SupportTools/onecommand/cell_group --vmstat="-a 5 5"
以上的例子只是用于简单介绍dcli的用法，如果嫌这个命令行太长，甚至可以使用linux的alias将其简化。
总之dcli还是非常强大的，Exadata用户几乎可以只在DB节点一就能完成大量平时需要频繁切换节点的重复无聊的工作。如果能用好dcli，无疑可以大大减轻Exadata管理员的工作。但是需要注意的是这种命令因为是在多节点分布式执行，其影响的范围是非常广的，所以如果要做的工作是非检查性的工作，需要特别的谨慎。如果您用dcli在所有节点执行了一个rm -rf /的操作，那么估计也离下岗不远了。
我曾经就遇到某个客户执行了一条这样的语句（这条命令危害非常大，我这里只是举一个例子说明，且不可放到生产环境中执行！），结果导致数据库无法启动，最后只能重装GI和rdbms了。
[root@dm01db01 ~]# dcli -g /opt/oracle.SupportTools/onecommand/dbs_group -g root "chown -R oracle:oinstall /u01/app" [root@dm01db01 ~]# dcli -g /opt/oracle.SupportTools/onecommand/dbs_group -g root "chomod -R 775 /u01/app"
我个人建议，在进行信息获取或者检查工作的时候可以大量使用dcli来减轻重复性劳动，但做真正变更之前需要额外谨慎反复检查确认其命令是否正确可行。做复杂而重要的变更的时候，最好不要使用dcli，宁愿多花一些时间，以防止万一。
目前这个dcli无法下载到，我会上传这个工具到本文的回复中。此工具在Linux下无需安装，直接可以执行, 读者有多节点集群测试环境可以自行挖掘其更多的功能。
以上
