性能与安全的权衡
对于数据库调优而言，没有绝对的性能也没有绝对的安全。正如鱼和熊掌不能兼得一样，是不能全然兼顾的。就像是矛和盾此消彼长。以下就对照较常见的几个因素做一个简要的阐述：
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、并发的用户和事务数量：
这是对于系统资源损耗情况的讨论，不能单从资源消耗多就推断系统性能有问题，由于对于资源的使用上。比方说当使用多时能够接受非常多的用户操纵，在单位的时间内能够完毕非常多的事务。为了做到这点，负荷必定大。性能消耗必定多。这就是一个平衡点，一般须要保证系统在一个平稳的状态下执行后，尽可能多的去承担用户的訪问为佳（即事务量越多越好）。
优化的影响因素有非常多，这仅仅是对某几点的一个简单阐述，在博客中会逐渐的通过几方面去扩展优化。假设感兴趣的话，能够关注一下。
