数据库技术问题解析.docx

oracle的体系
　　oracle的体系很庞大，要学习它，首先要了解oracle的框架。在这里，简要的讲一下oracle的架构，让初学者对oracle有一个整体的认识。
　　1、物理结构（由控制文件、数据文件、重做日志文件、参数文件、归档文件、密码文件组成）
　　控制文件：包含维护和验证数据库完整性的必要信息、例如，控制文件用于识别数据文件和重做日志文件，一个数据库至少需要一个控制文件
　　数据文件：存储数据的文件
　　重做日志文件：含对数据库所做的更改记录，这样万一出现故障可以启用数据恢复。一个数据库至少需要两个重做日志文件
　　参数文件：定义Oracle 例程的特性，例如它包含调整SGA 中一些内存结构大小的参数
　　归档文件：是重做日志文件的脱机副本，这些副本可能对于从介质失败中进行恢复很必要。
　　密码文件：认证哪些用户有权限启动和关闭Oracle例程
　　2、逻辑结构（表空间、段、区、块）
　　表空间：是数据库中的基本逻辑结构，一系列数据文件的集合。
　　段：是对象在数据库中占用的空间
　　区：是为数据一次性预留的一个较大的存储空间
　　块：ORACLE最基本的存储单位，在建立数据库的时候指定
　　3、内存分配（SGA和PGA）
　　SGA：是用于存储数据库信息的内存区，该信息为数据库进程所共享。它包含Oracle 服务器的数据和控制信息, 它是在Oracle 服务器所驻留的计算机的实际内存中得以分配，如果实际内存不够再往虚拟内存中写。
　　PGA：包含单个服务器进程或单个后台进程的数据和控制信息，与几个进程共享的SGA 正相反PGA 是只被一个进程使用的区域，PGA 在创建进程时分配在终止进程时回收
　　4、后台进程（数据写进程、日志写进程、系统监控、进程监控、检查点进程、归档进程、服务进程、用户进程）
　　数据写进程：负责将更改的数据从数据库缓冲区高速缓存写入数据文件
　　日志写进程：将重做日志缓冲区中的更改写入在线重做日志文件
　　系统监控：检查数据库的一致性如有必要还会在数据库打开时启动数据库的恢复
　　进程监控：负责在一个Oracle 进程失败时清理资源
　　检查点进程：负责在每当缓冲区高速缓存中的更改永久地记录在数据库中时,更新控制文件和数据文件中的数据库状态信息。
　　归档进程：在每次日志切换时把已满的日志组进行备份或归档
　　服务进程：用户进程服务。
　　用户进程：在客户端，负责将用户的SQL 语句传递给服务进程，并从服务器段拿回查询数据。
　　5、oracle例程：Oracle 例程由SGA 内存结构和用于管理数据库的后台进程组成。例程一次只能打开和使用一个数据库。
　　6、SCN(System Change Number)：系统改变号，一个由系统内部维护的序列号。当系统需要更新的时候自动增加，他是系统中维持数据的一致性和顺序恢复的重要标志。
　　四、深入学习
　　管理：可以考OCP证书，对oracle先有一个系统的学习，然后看Oracle Concepts、oracle online document,对oracle的原理会有更深入的了解，同时可以开始进行一些专题的研究如：RMAN、RAS、STATSPACT、DATAGUARD、TUNING、BACKUP&RECOVER等等。
　　开发：对于想做Oracle开发的，在了解完Oracle基本的体系结构之后，可以重点关注PL/SQL及Oracle的开发工具这一部分。 PL/SQL主要是包括怎么写SQL语句，怎么使用Oracle本身的函数，怎么写存储过程、存储函数、触发器等。 Oracle的开发工具主要就是Oracle自己的Developer Suite（Oracle Forms Developer and Reports Developer这些），学会如何熟练使用这些工具。
五、开发经验及常见问题
常见Oracle安装问题说明
1.问题集锦一
2.Oracle9i在RedhatLinux8.0中的安装详细步骤
3.问题集锦二
4.如何配置和使用iSQL*Plus
5.Oracle9i中Data Guard的新特性以及配置使用
常见Oracle入门问题说明　
1.关于Linux下DBSTART和DBSHUT脚本中需要修改的地方
2.如何将EXP出来的数据IMP进不同的表空间
3.如果系统中安装了多个数据库实例，如何修改默认SID
4.Oracle9i初始化参数注解
5.关于Oracle数据库的升级(Migration)
常见Oracle开发问题说明
Oracle技巧与提示
1.如何修改数据库的字符集
2.如何查看Control File中保存的内容
3.Oracle9i(Version 9.2)SYS_CONTEXT函数的用法以及同USERENV函数的比较
ORACLE数据库就是一个数据的集合，数据库的目的是存储和检索数据。数据库服务器的主要工作是管理信息，数据库服务器在一个多用户的环境下管理大量的数据，使很多用户可以并发访问共同的数据。数据库服务器同时也防止未经授权的数据库访问，以及保护数据的安全可靠。可以从多个角度来理解数据库。第一个角度是从静态和动态的角度。从静态的角度来看ORACLE数据库，ORACLE数据库是由一系列文件组成的。从动态的角度来看ORACLE数据库，ORACLE数据库是由后台进程和各种缓冲区组成的。   
     另外我们可以从逻辑和物理的角度来看ORACLE数据库。从逻辑的角度来看ORACLE数据库，ORACLE数据库包含了方案（SCHEMA）、数据块(data block)、扩展（extents）、段（segments）和表空间（tablespace）。从物理的角度来看ORACLE数据库，可以看到ORACLE的静态结构及相应的工具。
从静态结构上来讲，ORACLE是由一系列文件组成的。这些文件存储了ORACLE数据库的所有内容，文件分为以下几类：
参数文件
口令文件
控制文件
数据文件
在线日志文件
归档日志文件
     参数文件和口令文件是ORACLE数据库最基本的文件。在数据库创建之前，需要首先建立这两个文件。 ORACLE口令文件式是用于存放DBA(在ORACLE 9i之前的版本，还包含internel)帐号的口令。ORACLE参数文件包含ORACLE的启动参数。ORACLE的参数文件和口令文件位于$ORACLE_HOME/dbs目录下(对于windows系统，这些文件位于$ORACLE_HOME\DATABASE目录下)。口令文件的名称为pwd.ora，参数文件（PFILE）的文件名为init.ora。ORACLE9i开始提供服务器参数文件SPFILE（一种二进制的参数文件），SPFILE的文件名格式为spfile.ora。
     要注意的是，从8.0版本的ORACLE开始，在$ORACLE_HOME/dbs目录下的参数文件(PFILE)其实只是一个软链接而不是真正的文件，该文件指向：
$ORACLE_BASE/admin//pfile/init.ora
或者
$ORACLE_BASE/admin//script/init.ora
注：在WINDOWS操作系统下，存放参数文件和口令文件的目录为：
$ORACLE_HOME/database
由于不支持软链接，所以在WINDOWS下，该文件中只有一行代码：
include=c:\oracle\admin\ora92\pfile\init.ora
也就是将该目录下的参数文件引用过来。
从ORACLE 9i开始，数据库引入了服务器参数文件，服务器参数文件的优点是管理更加方便，不方便的地方是服务器参数文件是二进制的，无法直接编辑。
ORACLE 9i和以前的版本不同，采用了一种二进制的参数文件SPFILE。同时保留了对原有的文本参数文件的支持。在$ORACLE_HOME/dbs下存放SPFILE文件(如果是NT，$ORACLE_HOME/database)。ORACLE启动的时候会按照如下顺序查找参数文件：
$ORACLE_HOME/dbs/SPFILE.ORA
$ORACLE_HOME/dbs/spfile.ora
$ORACLE_HOME/dbs/init.ora
指定的pfile
如果需要，可以使用下面的方法指定一个启动参数文件：
sqlplus /nolog
sql>connect sys/... as sysdba;
sql>startup pfile=$ORACLE_HOME/dbs/init.ora;
采用服务器参数文件后，参数文件的修改就相对容易了一些。可以通过ORACLE提供的指令修改:
ALTER SYSTEM SET = SCOPE=’SPFILE’;
对于习惯于修改文件的人，可以使用下面方法实现类似8i的参数修改。首先通过下列语句创建一个文本的参数文件。
sql>create pfile=’....’ from spfile;
生成参数文件后可以手工修改。但是每次修改后要使用下面语句生成信的SPFILE。
SQL>CREATE SPFILE=’....’ FROM PFILE=’....’;
      要注意的是这些操作要在数据库关闭的情况下进行，如果在创建SPFILE的时候如果文件名和正在活跃的数据库的SPFILE相同，会导致创建失败。如果你习惯以前的文本方式的参数文件，可以在创建了INIT文件后删除SPFILE，这样就可以使用文本的参数文件了。
1.3 理解什么是Oracle 数据库(2)
     密码文件在数据库创建之前就创建了。密码文件存放的位置为：
$ORACLE_HOME/dbs(在WINDOWS系统下为$ORACLE_HOME/database)
     可以通过orapwd工具来创建口令文件。命令格式：
orapwd file= password= entries=
FNAME:要创建密码文件的名字
Password：SYS帐号的口令
Users:系统中可以有多少个DBA或OPER帐号
      在ORACLE数据库系统中，用户如果要以特权用户身份（INTERNAL／SYSDBA／SYSOPER，ORACLE 9i的版本，internal帐号被取消了，其功能由sys帐号继承）登录ORACLE数据库可以有两种身份验证的方法：
使用与操作系统集成的身份验证
使用ORACLE数据库的密码文件进行身份验证。
         因此，管理好密码文件，对于控制授权用户从远端或本机登录ORACLE数据库系统，执行数据库管理工作，具有重要的意义。 ORACLE数据库的密码文件存放有超级用户INTERNAL／SYS的口令及其它特权用户的用户名／口令。 在创建一数据库的时侯，在$ORACLE_HOME/dbs目录下会创建一个与之对应的密码文件，文件名为PWD.ora。此密码文件是进行初始数据库管理工作的基础。在此之后，管理员也可以根据需要，使用工具ORAPWD手工创建密码文件。
有了密码文件之后，需要设置初始化参数REMOTE_LOGIN_PASSWORDFILE来控制密码文件的使用状态。 在ORACLE数据库实例的初始化参数文件中，此参数控制着密码文件的使用及其状态。它可以有以下几个选项：
NONE：指示ORACLE系统不使用密码文件，特权用户的登录通过操作系统进行身份验证；
EXCLUSIVE：指示只有一个数据库实例可以使用此密码文件。只有在此设置下的密码文件可以包含有除INTERNAL／SYS以外的用户信息，即允许将系统权限SYSOPER／SYSDBA授予除INTERNAL／SYS以外的其它用户。
SHARED：指示可有多个数据库实例可以使用此密码文件。在此设置下只有INTERNAL／SYS帐号能被密码文件识别，即使文件中存有其它用户的信息，也不允许他们以SYSOPER／SYSDBA的权限登录。此设置为缺省值
在REMOTE_LOGIN_PASSWORDFILE参数设置为EXCLUSIVE、SHARED情况下，ORACLE系统搜索密码文件的次序为：查找ORA_SID_PWFILE环境变量（它为密码文件的全路径名）；若未找到，则查找ORA_PWFILE环境变量；若仍未找到，则使用缺省值$ORACLE_HOME/dbsPWD.ORA。
当初始化参数REMOTE_LOGIN_PASSWORDFILE设置为EXCLUSIVE时，系统允许除INTERNAL／SYS以外的其它用户以管理员身份从远端或本机登录到ORACLE数据库系统，执行数据库管理工作；这些用户名必须存在于密码文件中，系统才能识别他们。因为密码文件不管是在创建数据库实例时自动创建的，还是使用工具ORAPWD.EXE手工创建的，都只是包含INTERNAL／SYS用户的信息，所以在实际操作中，可能需要向密码文件添加或删除其它用户帐号。
由于仅被授予SYSOPER／SYSDBA系统权限的用户才存在于密码文件中，所以当向某一用户授予或收回SYSOPER／SYSDBA系统权限时，他们的帐号也将相应地被加入到密码文件或从密码文件中删除。由此，向密码文件中增加或删除某一用户，实际上也就是对某一用户授予或收回SYSOPER／SYSDBA系统权限。
要进行此项授权操作，需使用SYSDBA权限（或INTERNAL帐号）连入数据库，且初始化参数REMOTE_LOGIN_PASSWORDFILE的设置必须为EXCLUSIVE。具体操作步骤如下：
建相应的密码文件
设置初始化参数REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
使用SYSDBA权限登入
　　SQL>CONNECT　SYS／internal_user_passsword　AS　SYSDBA；
启动库实例并打开数据库
创建相应用户帐号，对其授权（包括SYSOPER和SYSDBA）
授予权限：GRANT　SYSDBA　TO　user_name；
收回权限：REVOKE　SYSDBA　FROM　user_name
      如果REMOTE_LOGIN_PASSWORDFILE=SHARED，那么是不能向口令文件添加用户的，比如：
SQL>SHOW PARAMETER REMOTE_LOGIN_PASSWORDFILE
NAME                                 TYPE        VALUE
------------------------------------ ----------- -----------------
remote_login_passwordfile            string      SHARED
SQL> grant sysdba to scott;
grant sysdba to scott
*
ERROR 位于第 1 行:
ORA-01994: GRANT 失败: 无法添加用户至公用口令文件
    对于密码文件，可以通过下面的方法进行管理：
查看密码文件中的成员：
可以通过查询视图V$PWFILE_USERS来获取拥有SYSOPER／SYSDBA系统权限的用户的信息，表中SYSOPER／SYSDBA列的取值TRUE／FALSE表示此用户是否拥有相应的权限。这些用户也就是相应地存在于密码文件中的成员。
扩展密码文件的用户数量：
当向密码文件添加的帐号数目超过创建密码文件时所定的限制时，为扩展密码文件的用户数限制（ORAPWD.EXE工具的MAX_USERS参数），需重建密码文件，具体步骤如下：
询视图V$PWFILE_USERS，记录下拥有SYSOPER／SYSDBA系统权限的用户信息
关闭数据库
删除密码文件
用ORAPWD新建一密码文件
将步骤a中获取的用户添加到密码文件中
修改密码文件的状态
密码文件的状态信息存放于此文件中，当它被创建时，它的缺省状态为SHARED。可以通过改变初始化参数REMOTE_LOGIN_PASSWORDFILE的设置改变密码文件的状态。当启动数据库事例时，ORACLE系统从初始化参数文件中读取REMOTE_LOGIN_PASSWORDFILE参数的设置；当加载数据库时，系统将此参数与口令文件的状态进行比较，如果不同，则更新密码文件的状态。若计划允许从多台客户机上启动数据库实例，由于各客户机上必须有初始化参数文件，所以应确保各客户机上的初始化参数文件的一致性，以避免意外地改变了密码文件的状态，造成数据库登陆的失败。
修改密码文件的存储位置：
密码文件的存放位置可以根据需要进行移动，但作此修改后，应相应修改环境变量有关指向密码文件存放位置的参数或环境变量的设置。
删除密码文件：
在删除密码文件前,应确保当前运行的各数据库实例的下面参数是NONE状态：
REMOTE_LOGIN_PASSWORDFILE = NONE
在删除密码文件后，若想要以管理员身份连入数据库的话，则必须使用操作系统验证的方法进行登录。
      制文件是数据库中的重要文件。控制文件记录ORACLE数据库的一些重要的状态，并可以通过控制文件来控制数据库的一致性。控制文件中包含下列信息：
数据库的结构
数据库日志及归档的情况
所有数据文件的同步信息
RMAN备份的恢复目录（在NOCATALOG模式下，恢复目录写在控制文件中）
       文件是系统中十分重要的文件，一旦控制文件损坏可能造成数据库崩溃，因此数据库安装的时候至少会创建2个控制文件（可以根据需要增加控制文件的数量）。在设置控制文件的时候，把多个控制文件存放在不同的物理磁盘上，这样可以保证控制文件的安全。当一个控制文件发生故障的时候，可以使用其他的控制文件来恢复。
我对技术方向的一些反思
关于SSD
去年，我们曾经使用了一批SSD的PC，用来做数据库的服务器，用来提高数据库服务器的IO能力。但是从目前的使用情况来看，如果将SSD作为主存储，存在一些问题：
首先，SSD的稳定性还不够好，我们碰到了一些SSD盘损坏和SSD与机器不兼容的情况发生。
第二，SSD的容量盘都比较小，考虑到稳定性的问题，如果做RAID会进一步损失容量，性价比不高。
第三，SSD属于NAND类型的flash，写操作不仅会产生“磨损”，而且随着碎片的不断增加，写操作的性能会不断下降。
目前看来，SSD并不太适合作为数据库的主存储，写操作并不是SSD的特长，而且作为主存储的代价过高，SSD更加适合作为内存和磁盘之间的一层cache，降低读操作的延迟时间，我们将其称为flash cache。Oracle 11g R2中就提供了这样的功能，Oracle exadata V2配置了flash卡用来做flash cache，可以提供非常高的IOPS。对于MySQL数据库，Google和Facebook都提出了基于MySQL数据库的解决方案。
将SSD和Flash卡配置在PC服务器上，与普通SAS或者SATA磁盘混插，采用数据库flash cache技术，可以达到一个非常理想的性能，代价又不是特别高，我们也在考虑采用MySQL的flash cache架构。但是，如果你采用大型的存储设备，比如EMC和HDS，存储的cache实际上已经起到了一个二级缓存的作用，就没有太多必要使用SSD或者Flash卡了。
使用SSD还可以解决写操作的响应延迟，比如Oracle数据库的redo，因为每次commit都必须物理写入到磁盘上，所以将redo放在SSD上，可以提高写的响应延迟，但是不必将数据文件放在SSD上，因为他们并不是必须被写入的。这里要注意的是，SSD可能出现随着大量的写操作性能下降的情况。在我们的测试中，SLC的写能力比较稳定，而MLC的写能力会出现下降的情况。
SSD一定有光明的未来，取代磁盘只是个时间问题，只是我们还需要等待技术更加成熟，价格更加便宜。
关于可扩展的数据库架构
数据库分片(Sharding)是最简单实用的方案之一，将一个集中式的数据库拆分为很多小的数据库，从而获取数据库横向扩展的能力。但是，Sharding也带来一些问题：第一，应用可能需要进行大幅度的修改，以适应数据库拆分的变化。我们通过数据库代理软件来解决应用透明访问的问题，比如Amoeba，让数据库对应用透明，从而降低应用修改的复杂程度。第二，Sharding带来了一些应用上的限制，比如join，复杂查询和事务，要想解决这个问题比较困难，但是我们可以选择在适当的应用场景来使用，比如：在我们实际的应用场景中，绝大部分压力来自于商品，订单，交易等这类应用，其特点是：访问简单，数据量大，查询压力大。这类应用往往占到系统85%以上的压力，他们是非常适合做数据库拆分的。还有些应用是不适合做拆分的，比如一些查询复杂，事务要求高的应用，采用集中式数据库是比较合适的。我们通过应用场景的不同，选择不同的方案，既可以降低数据库压力，又可以降低应用的复杂程度。
还有一种常见的解决方案，在数据库前端增加一层cache，比如内存数据库，搜索引擎，KV cache等等，属于读写分离架构的一种，通过cache层有效缓解数据库的读压力，提高整个系统的处理能力。在这种架构中，由cache层承载了大量的数据访问，而数据库则退化为一个单纯的数据存储。在我们的系统架构中，就大量使用了memcache作为数据库的外部cache，淘宝也开发了自己的分布式KV  cache（Tair）。
作为DBA来说，我们也常常使用数据本身的功能去解决问题，比如Partition功能，但是它依然受限于单个database的处理能力，如果我们预期到单一数据库可能产生性能瓶颈时，就需要考虑借助一些应用架构去解决问题，而不是总是局限在数据库本身的功能上。
事实上，解决方案都不是孤立存在的，这几种方案经常混合在一起使用，比如Facebook的架构中，就是利用MySQL数据库和memcache，通过Sharding和读写分离等架构，从而使整个网站具备非常高的性能和扩展能力。我们在实际解决问题时，也是如此，从数据库本身的优化，数据库内做分区，数据库拆分，利用memcache作读写分离，多数据库中心架构等等。

关于Oracle和MySQL
Oracle更适合集中式数据库架构，而MySQL数据库更适合分布式架构，在两种架构并存的环境下，我们用MySQL完全去替换Oracle是不现实的。
从公司战略的角度出发，逐步降低对Oracle的依赖，这是一个大的方向和目标，但并不意味着我们需要把所有的应用都迁移到MySQL数据库上，从纯技术的角度分析，这并不合理。
我对MySQL和Oracle的想法是：分布式架构采用MySQL数据库，集中式架构采用Oracle数据库，前者通过数据拆分（Sharding）等手段，解决海量数据处理和弹性扩展的问题，集中式Oracle数据库则用于保存核心数据，提供简单可靠的数据存储和访问服务。合理的使用Oracle和MySQL数据库，集中式架构和分布式架构共存，不仅可以控制Oracle数据库的压力和规模，而且可以降低整体开发成本和维护成本。
关于小型机和存储
虽然说近些年来PC服务器的性能得到了很大的提高，甚至已经超过了小型机，但是小型机也不是一无是处，在稳定性，管理性和维护性等方面，小型机都要比PC服务器高出不止一个档次。其缺点就是价格昂贵，容易对硬件厂商产生依赖。
长远来看，我们要控制小型机使用的规模，但并不意味着要替换掉所有的小型机，对于核心应用的Oracle数据库，我认为小型机还是有价值的，起码在可用性方面有保证。对于MySQL数据库，我们大量采用PC服务器，配合数据库拆分和高可用架构，可以充分利用单台PC服务器的处理能力，又保证整个MySQL数据库集群的可用性。
Oracle和MySQL数据库对于机器的选型也有差异，Oracle选择小型机或者比较高端的PC服务器，比如四路Intel 7500系列，最高可以配置四路六核或八核CPU，在性能上已经超过了我们使用的IBM小型机。MySQL则选择处理能力与IO能力均衡的服务器，通常会配置比较多的本地磁盘，比如双路Intel 5500或者5600系列，本地配置12-16块磁盘，甚至配置SSD或者flash卡。
对数据库而言，存储设备非常重要，通常情况下，Oracle数据库会选择中高端的存储设备，而MySQL只配置PC服务器上本地磁盘或者低端的磁盘扩展柜。因为Oracle的高可用策略通常都要基于共享的存储设备实现（比如RAC，Veritas VCS等），所以SAN存储几乎是必须的选择，而MySQL的高可用策略是基于复制的，并不需要共享的存储设备。（当然，Oracle也有data guard的方式，但是DG的切换过程复杂，需要人工干预，作为高可用策略并不适合，更多是作为一种容灾和备份的机制）。
总的来说，硬件的选择与数据库本身的特性和应用架构有密切关系。从对主机的资源利用率上看，Oracle可以充分利用机器的计算能力，而MySQL对SMP架构的支持比Oracle差很多，单台MySQL数据库可能无法完全利用主机的处理能力，所以MySQL主机配置过多的CPU也是一种资源浪费。
关于“去I/O/E”的策略（分别代表IBM，Oracle，EMC），我个人的观点是“合理使用”，而不是为了去而去。不管是数据库的选择还是硬件的选择，我们的目标应该是不依赖于某个厂商，掌握主动权和话语权，这才是最重要的。
关于NoSQL和Database
NoSQL现在非常火，我也写了一些鸡毛蒜皮的文章介绍NoSQL，NoSQL的出现并不是为了替代database，而是在某些特定的领域内解决问题，所以每个NoSQL产品都有其鲜明的特点，相比之下，Database经过这么多年的发展，已经发展成为非常成熟的商业产品，而NoSQL现在大部分还处于成长的阶段。
NoSQL产品的优势在于：扩展性，灵活的数据模型（非关系型），大规模数据处理等方面，Database的优势在于：通用解决方案，成熟度，运维成本，使用成本等方面。我始终认为他们之间不是替代的关系，而是互补的关系，未来在Alibaba的使用场景中，Database应该还是首选的数据库处理和存储方案，但是在大规模的数据处理和数据仓库计算方面，NoSQL应该可以找到大量的应用场景。
现在我们做技术方案时，往往面临很多选择，但是选择太多未必是件好事，我们在选择的过程中往往会加入个人的喜好，比如对某个技术的喜好和掌握程度，甚至为了证明某些能力，而选择一些并不熟悉的技术，虽然它非常先进，但可能并不适用。每种技术都有其存在的合理性，但是引入过多技术必然增加成本和风险，比如facebook，他们利用MySQL和memcache就解决了绝大部分的问题，而很火的cassandra，在facebook只是很小的一个应用而已。相比较而言，我们使用的技术要多得多，我建议在选择NoSQL和Database产品时，选择简单和成熟的技术方案，后期开发和运维成本都是需要考虑的。
关于DBA
DBA不应该仅仅局限于某个数据库产品，而应该更全面的了解开发架构方面的知识，甚至需要具备开发能力，比如针对MySQL数据库进行修改和优化，这也将大大提高DBA解决问题的能力。
DBA的价值不仅仅在于维护数据库本身，而应该在数据存储方案的选择上做出最专业的判断，这是DBA最大的价值所在。
关于技术发展趋势
我在公司五年多了，最初的数据库就是采用PC服务器，然后我们统一把他们整合到小型机上的集中式数据库，把MySQL换成Oracle，而现在我们又要把小型机换成PC服务器，把集中式Oracle数据库拆分成MySQL数据库集群，这不是简单的轮回，而是技术发展的结果。
虽然现在的发展趋势是分布式架构，但是说不定过几年又会出现超级计算机，从而又走向集中式的道路。我们要做的是能够看到3年内技术发展的一个方向，适应技术发展的潮流，并不断调整目标，在解决问题的过程中不断优化。问题和技术都是不断发展的，试图设计一个完美的解决方案是不现实的，在一个问题被解决后，一定会有新的问题冒出来。
选择简单但是不完美的技术解决问题，先做！然后再不断优化。如果不去尝试，我们永远也不知道下一步要做什么，总是停留在对技术方案本身优劣的讨论上，是没有意义的。
人总是在不断反思，不断否定自我的过程中进步的，技术发展也是一样。
Oracle cluster使用场景分析
Oracle中普通的表称为堆表（heap table），堆表中的数据是无序存放的，往往在使用一段时间后，数据就变得非常无序。如下图所示，索引中相同的key对应的数据存放在不同的block中，这时，如果要通过索引查询某个key的数据，就需要访问很多不同的block，代价非常高。

Oracle中有一个统计信息clustering factor，它就是用来反映索引中键值在表中的有序程度，clustering factor的值如果接近表的blocks的数量，表明数据在表中的是有序的，而如果这个值接近表的行数，则表明表中的数据是无序存放的。因为clustring factor对于索引查询的影响很大，所以在CBO计算cost时，这个值非常重要。
我们可以通过创建一个单表的hash cluster，将相同键值的数据物理存放在一起，达到提高性能的目的。创建cluster有两个最重要的参数：hashkeys和size，前者表示cluster中有多少个不同的键值，后者表示每个键值需要分配的空间。因为hash cluster的空间是预先分配的，这两个值的正确设置对cluster的性能影响非常大。hashkeys设置过大，会造成空间浪费，而如果设置过小，则会产生大量的hash碰撞，极大影响性能。size也是一样，设置过大会浪费空间，而设置过小，数据超过预先分配的空间时，会通过链接方式存放在溢出段中，影响性能。而这两个值一旦设置，就无法更改，除非重建cluster。
hash cluster简单的说就是通过预先分配空间的方式，将相同key的数据存放在一起，以提高查询性能的一种手段，所以准确的设置hashkeys和size参数是使用hash cluster的关键，使用的前提是key的数量是可以估算的，而且每个key的数据是基本平均的。但是，在实际使用的环境中，数据量的变化往往是不可预知的，这也造成hash cluster的应用场景非常有限。
Index cluster和hash cluster类似，只不过index cluster是通过索引实现数据定位，而且index cluster的空间是动态分配的，但是同样存在正确设置size参数的问题，设置过大过小都会产生性能问题。
个人观点：Oracle cluster更适合相对静态数据的存储，对于OLTP应用来说，cluster在大部分情况下都不太适用，因为我们都无法预估到数据量的变化，根本无法合理设置cluster的参数。
任何技术都要找到合适的应用场景，有利一定有弊，有些技术确实是看上去很美，但是并不实用，而有些方案看上去很土，但是可以解决问题，找到最合适的就好。
如果哪位兄弟有oracle cluster解决实际问题方面的案例，也请和我一起交流。
写在3PAR被HP收购之后
3PAR最终被HP收购，想想HP一直没什么可以拿得出手的存储产品，高端的XP系列其实是HDS的USP，而与3PAR理念接近的EVA，始终没有进入高端行列。不知道HP收购3PAR后，是用来替换XP还是EVA系列。
通过我这几年使用硬件的经验来看，对HP的产品始终不太感冒。产品路线不清晰，小型机性能不佳，存储没有特色，PC服务器故障率高，价格没有优势，服务也很一般，销售换了一茬又一茬。
对于3PAR这个产品，我还是挺有好感的，设计理念很有特色，在实际测试中性能不俗，印象最深刻的是命令行界面非常好用，对于运维人员来说，这点是非常重要的。当初，曾经写过一篇文章介绍3PAR的产品：我看3PAR，有兴趣的可以看看。
随着技术的发展和公司策略的转变，我们对小型机和高端存储的需求已经越来越少了，分布式计算已经成为未来发展的趋势，当然，在传统行业中，这种高端硬件还是很有市场的。
在国外，这种收购的案例非常多，被收购的小公司都有非常鲜明的特点，大公司通过收购来提升自我的竞争力，小公司则在收购中得到收益，鼓励更多人去创新，形成良性循坏。但是在国内，这种案例就非常少见，大公司占有绝对优势，可以轻松的通过模仿等手段，挤垮这些小公司。归根结底，还是创新不够的原因，所以模仿的成本很低，比如微博，团购网等等，几乎都是照搬国外的模式，又没有太多技术门槛，所以就变成了大家一起上的局面。
Alibaba最近也收购了一些公司，但是基本都在电子商务这个领域，我觉得这点公司做的挺好，坚守在自己的领域。最近有人骂腾讯，其实腾讯没做错什么，只是什么都想做，树敌太多。我觉得每个企业都应该有自己的道德底线，不能什么赚钱就做什么，价值观也很重要。
附：《我看3PAR》，发表于2008年4月
最近测试了3par的存储，这个厂商在存储领域算是比较新的。以前看myspace的架构时，才第一次听说了这个产品，目前在国内才刚刚开始做。
这个存储有一些特点：
1.中端存储高端化：3PAR定为于高端存储，但是它的架构有点类似中端存储的架构，有控制器的概念，最多可以有8个控制器（S400最多有4个控制 器，S800可以有8个），控制器之间由一个网状背板连接起来，每个控制器有两个INTEL的CPU负责控制指令，还有一个3PAR自己控制器的ASIC 完成数据移动。普通的中端存储，一个LUN只能属于一个控制器，用户必须将LUN人工分布到两个控制器上，而3PAR每个LUN实际上是由多个控制器并行 处理的。
2.非常有特点的盘盒：3PRA插盘的方式非常独特，和其他存储都完全不同，在4U高度的盘盒中，有10个盘包，每个盘包可以纵向插入4块盘，相当于其他 存储一块盘的位置插入了四块，所以3PAR的盘的密度非常高。当然这也有问题，比如在换盘时，每次需要将整个盘包拔出，或者盘包自身的背板损坏，可能造成 数据丢失等等。不过3PAR已经考虑了这些情况，并有解决方案。
3.虚拟卷管理：第一层：每个盘都被划分为256M的小块(chunklet)，由于每个盘盒都和两个控制器相连，所以这些存储块都有两个访问通道。第二 层：将这些存储块，基于RAID类型和存储块的位置组成逻辑盘(LD)。第三层：将一个或多个LD映射成为了一个虚拟卷(VV)，并最终以LUN的形式输 出给主机(VLUN)。这样可以将IO分散到系统所有的磁盘，光纤连接和控制器上，而不象某些存储，必须要借助主机的LVM才能实现。如果我们使用文件系 统或者ASM的话，将会很方便。另外一个特点就是管理非常方便，只需要告诉系统我要多大的LUN，其他系统会自动完成。
4.精简配置：也叫做瘦存储(Thin Provisioning)，就是将”使用的存储”和”分配的存储”分开了。比如用户规划需要2T的空间，但是目前只需要500G空间，这样存储可以实际 只有500G空间，但是告诉主机我有2T的空间。对主机来说，存储的管理将是透明的，当未来存储扩容后，主机不需要再做任何配置工作。
5.动态优化：当存储扩容时，可以动态的将数据重新分布，更改RAID类型，硬盘类型等等。
6.性能：从测试的结果看，3PAR表现相当不错，iops和相应时间都很理想。测试结果就不写了，免得有做广告的嫌疑。
7.界面：个人觉得3PAR的命令行界面很好用，图形界面没见过，不便评论。
浅谈数据库系统中的cache
Cac