工作两年来的一点积累和沉淀

毕业已经两年了，在公司也已经两年了，做个总结以示纪念。

从毕业到现在从事的职位，由开发转为应用DBA，再到现在的核心库DBA。工作职能一直在逐渐变化。但都是大同小异。当然在公司遇到了很多牛逼的同时

有两个oracle的ACE ：老楼和童家旺，能天天跟这么多大牛一起共事，深感荣幸。自己的成长也比较快。从一个开发成为了掌管核心交易数据库的DBA。

下面从个人成长上面谈谈我自己对数据架构以及对应用建构的抽象的理解。

作为一个DBA，管理好公司的数据库无非两个事情: 数据的可用性以及容灾。

A. 可用性角度来讲包含了：　数据的可靠性，数据（库）的稳定性，性能

B.容灾角度来看数据库: 数据部丢失和高可用，也就是数据库的高可用架构的内容。

从A部分来看主要是数据库单体上的一些特征 包括了主机层面和数据库层面的东西，本身数据库的可靠性和稳定性跟主机和操作系统有着密切的联系，

性能的话当然跟硬件也有着密不可分的干系，当然性能还跟应用系统数据库设计有关系，特别是索引的设计，都将直接影响sql的性能，这两年多来，

遇到的sql问题，90%都跟索引的设计有关系，要么是索引设计不当，要么是没有合适的可用的索引。还有更多的像oracle的执行计划走错的情况也很多。

索引设计不当，造成的问题通常修正对应的索引，或者添加合适的索引，正常情况，在项目上线前dba会对系统做sql review 已经结构变更操作，着都是为了减少有潜在风险的sql，当然不可能杜绝。

另外sql执行计划走错，要根据当时数据库的运行状况，做相应的操作， 正常情况是收集统计信息，或者添加profile,等等，当然可以对相关sql 做执行计划的稳固: outline, profile,sql baseline  等等。正常情况我们对11g版本都会打开sqlbaseline，来预防执行计划走错（一般是指变坏），降低风险。 

对B方面看，作为数据库工程师，或者运维工程师，在 数据可用或者应用系统可用，服务可用方面来做相关的数据架构和运维架构以及系统架构是必要的。

运维架构，数据架构，应用系统架构三者可谓是有着密不可分的联系。我根据自己工作中的情况和自己对其理解来加以概况和总结,首先作为dba 数据的高可用容灾方案

是非常必要的。

数据架构等级： 我们一般分为数据不可以丢失, 数据可以接受短暂丢失。我们主要关注第一种，第二种没有太大意义 .另外高可用方案的设计离不开成本的支持，

每种方案都有其对应的成本，我们能做的就是在方案和成本之间达到一个平衡。就是我们认为的最佳方案 。

首先对oracle 来讲，做到同机房不丢数据还是比较容易的，

1.一般情况 简单的dataguard, 采用同步传输应用日志，可以达到数据库不丢失数据，但是会带来性能问题每个事务在主库进行commit 必须等到 standby 同步commit 之后

才可以返回，如若在性能允许的场景，可以使用该方案，优点是陈本低廉，缺点是性能会差一些。

2.如果性能要求较高，第一种肯定是不可以的，但是我们可以在1的基础上进行双份redo来解决，就算数据库主库突然丢失数据，我们同样可以通过online的 redo 来恢复备库，使得备库达到主库的一致状态，前提是我们的redo必须可以在主库失效后能够获取到。这种方式可以进行异地机房部署

理论上着前面提到的只能叫做数据保护方案，还不能称得上是高可用方案，如果我们来通过对app的影响时间来看这种方案的影响时间还是比较长的。 数据库的的failover切换，加上域名的切换，到应用程序真正的恢复业务还是需要半个多小时的时间的，如果还需要恢复日志，这个时间会更长，如果全部都自动化会好一些。有没有更好的办法降低我们的服务可用时间呢？ 

这个当然有，