#1: 创建多个Oracle Homes
我最喜欢的最佳实践是关于多个Oracle Homes。下面将介绍这是怎么回事。当安装一个补丁或者一个补丁集的时候，我反对在现有的Oracle Home上安装这些补丁。相反，我建议新建一个Oracle Home，然后在这个新的Oracle Home上安装这些补丁。
比如，我在/app/oracle/db_1上创建第一个Oracle Home。当需要打一个补丁，我在一个不同的home上安装整个Oracle软件——/app/oracle/db_2——然后对它安装补丁。在安装和打补丁的过程中，原来的数据库一直在/db_1 Home中运行。当outage window出现的时候，我需要做的就是关闭Oracle;将Oracle Home指向db_2，再启动数据库。假如出现了问题，我可以将Oracle Home重新指回原先的目录。
总结传统的方法如下：
1. 关闭数据库
2. 给Oracle Home打补丁
3. 启动数据库
4. 假如存在问题
5. 关闭数据库
6. 回滚补丁
7. 启动数据库
第2步和第6步可能会花费三个小时，具体的时间依赖于补丁的数量。而在此期间数据库是停止的。
在新方法中：
1. 安装一个新的Oracle Home
2. 给新的Home打补丁
3. 关闭数据库
4. 将Oracle Home指向新的位置
5. 启动数据库
6. 如果出现问题
7. 关闭数据库
8. 将Oracle Home指向原来的位置
9. 启动数据库
数据库只有在第4步和第8步之间才是停止，这段停机时间最多几分钟，不超过一小时。
下面是这种方法的好处：
1. 停机时间显著降低，只是原有时间的六十分之一。
2. 由于不用回滚补丁，风险显著降低;你只要回退到老版本。
3. 你可以执行“diff”命令来比较这前后两个Home，看发生了哪些变化。你页可以发现多个Home之间的不同。
4. 你可以将同一台服务器上运行的多个数据库逐个的转移到新的Oracle Home上。
5. 使用目录(inventory)，你可以查看不同Oracle Home以及它们的补丁版本。
唯一的负面结果是空间消耗——你需要两个Oracle Home的空间。但是考虑到一个典型的Oracle Home占用大概4G或者更少的空间，这方面的影响还是无关紧要的。
#2:设置DB审计跟踪
在数据库创建过程中，在初始化参数文件中加入参数AUDIT_TRAIL = DB，可以为DB设置audit trail。在设置该参数之后，并不会马上开始审计，因为一定要对对象发出显式的AUDIT命令才开始审计。但是只有在这个参数设置为非FALSE值(这个参数的默认值)之后，命令才会生效。这个参数是非动态的，数据库必须重启才能改变AUDIT_TRAIL的值。为了避免修改参数的麻烦，通常将该变量设置为DB，即使你并不打算审计什么。这不会造成任何问题，而且你可以在时机成熟的时候开始审计。
#3: 不用使用.log
不要使用.log作为redo日志的扩展名。有些人可能会认为日志文件是多余的，而执行一个脚本删除所有的日志文件，这样做结果可能是失去所有的在线redo日志，从而强迫进行一次数据库恢复。相反，使用“redo”或者“rdo”作为redo日志的扩展名。
#4: 预演RMAN的恢复
在不进行真实的恢复的情况下，预先检查RMAN恢复，找出在恢复过程中会用到的所有的备份部分。这将消除在真实的恢复过程中发生缺少备份的情况。
#5: 当客户端运行在数据库相同的服务器上时，为这些客户端新建Oracle 用户
Oracle数据库服务器软件也包含了客户端的部分，让客户端能够连接到同一台服务器上的数据库。但是最佳实践是不使用初始的用户名;而是使用一个新的。比如，如果“oracle”是安装Oracle软件的用户，新建一个叫做“oraapp”的用户，用于安装客户端的软件。这个“oraapp”用户不应该是dba或者oinstall组的成员;因此该用户无法作为sysdba登陆到数据库上。新建一个叫“appgrp”的用户组，并且将用户oraapp加入这个组。所有的应用程序的用户也应该是appgrp组的成员。这样他们可以使用sqlplus，sqlldr和其他的程序，但是无法作为sysdba连接到数据库。
一条常见的实践是以数据库软件所有者的用户使用客户端软件。但是从版本10.2开始，Oracle改变了安全策略，取消了对Oracle Home的全局执行权限。这样唯一的选择是让应用用户作为dba组的成员，或者改变对Oracle Home的权限——两种方法都让数据库非常脆弱。