性能与安全的权衡
对于数据库调优而言，没有绝对的性能也没有绝对的安全。正如鱼和熊掌不能兼得一样，是不能完全兼顾的，就像是矛和盾此消彼长。下面就对比较常见的几个因素做一个简要的阐述：
1、多元化控制文件：
多个地方，意味着更安全，一个损坏了可以转储另外一个继续使用。但同样，越多也意味着IO压力越大，一般为2到3个控制文件多元化。比如：假设3个控制文件都损坏的概率已经相当低了，再多的控制文件也就没有意义了。因为一个控制文件损坏，数据库立刻就会崩溃，检查点的发生会产生预警信息，这样就可以根据提示人为的做出干预，尽快对其解决。
2、多元化日志组成员：
多远化日志组成员一样，越多也就意味着IO压力越大，但对于日志组，要根据实际生产环境去制定适宜的日志组个数、日志组成员的个数、日志组的大小。
3、经常产生检查点：
发生检查点以后，如果要做数据恢复的话，说明要从检查点以后数据进行恢复，这就意味着检查点发生的多，恢复的量级就少。即使数据丢失，也能确定发生这个检查点的时候，数据都写入到了数据文件里。但经常发生检查点对于性能上IO量会大。因为发生检查点时脏块会同步到磁盘上，设计脏块的目的就是一个脏块修改了很多次，在将脏块写入到磁盘的时候可以一次完成。有一点要提及的就是修改内存中的数据状态要比修改磁盘中的数据状态快很多，设想一下把多次修改内存中的状态，变成多次直接修改磁盘中的状态，会有怎样的变化。做一个极端化假设，脏块每次细微变化就触发一次检查点，把脏块写入到磁盘中，是保证了数据的安全性，但这就破坏设计缓冲区的目的。记住一点，写入磁盘的数据效率要远低于写入内存数据的效率。
4、数据文件备份：
没有备份，数据丢失是无法恢复的。要明确的知道，在做数据的备份的时候，会产生大量的读和大量的写，这个过程需要很大的IO，做的多对数据库是有影响的。但客户都会有一个最长的恢复时间（到达现场的时间、转储环节、recover环节，经过测试能满足客户要求的最长的停机时间），如恢复一周数据需多长时间，要有备份策略，在做备份之前要跟客户协调好，如果可以的话需要签署某些备份协议以保证双方应承担的义务和责任。
5、开启归档：
一般生产库均会开启归档，排除某些允许数据可以丢失的现场环境，实际工作中很少有不开归档的。一旦存在这种情况的话，往往数据是可以从其它途径恢复的。如把数据从库中导出，这样就可以接受非归档。举个例子可以不开归档，比如一个用于实验或分析的库，其中的数据是由另外的库导入的，这种情况就可以接受不开归档。
同样的，归档的路径越多，安全性越高，性能影响就会越大，这就是一个相互制衡的因素。
6、数据块检查：
举例：
SQL> show parameter check
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_block_checking string FALSE
db_block_checksum string TRUE
log_checkpoint_interval integer 0
log_checkpoint_timeout integer 1800
log_checkpoints_to_alert boolean FALSE
由上图的视图可以查询到db_block_checking参数：
FALSE：表示当从数据缓存区把数据往磁盘上写的时候，仅要求system表空间往下写的时候，是需要验证的，其它表空间不做验证；
TRUE：表示所有表空间在写脏块时都做验证。
该数据库检查越多，IO越多，但数据越安全。这就要看事务的重要程度了。
7、并发的用户和事务数量：
这是对于系统资源损耗情况的讨论，不能单从资源消耗多就判断系统性能有问题，因为对于资源的使用上，比如说当使用多时可以接受很多的用户操纵，在单位的时间内可以完成很多的事务。为了做到这点，负荷必然大，性能消耗必然多。这就是一个平衡点，一般需要保证系统在一个平稳的状态下运行后，尽可能多的去承担用户的访问为佳（即事务量越多越好）。
优化的影响因素有很多，这只是对某几点的一个简单阐述，在博客中会逐渐的通过几方面去扩展优化。如果感兴趣的话，可以关注一下。