@>startup ;
ORACLE instance started.

Total System Global Area  838860800 bytes
Fixed Size                  2087608 bytes
Variable Size             494929224 bytes
Database Buffers          335544320 bytes
Redo Buffers                6299648 bytes
Database mounted.
ORA-01113: file 5 needs media recovery
ORA-01110: data file 5: ‘/data/oracle/oradata/orcl/wt_tbs01.dbf’

有备份还好，没备份基本上只有把数据文件offline了。DBA准备打包回家吧。

经过无数次的测试，确认修改SCN号可以搞定。目前网上的文章，多少还是有些错误。经过反复的测试，确认没有问题。
我们直接使用BBED查看下当前SYSTEM TBS表空间的SCN号：

BBED> set file 1
FILE#           1

数据文件头就是第一个block块，因此我们不需要设置其他block块，
此外map可以显示block里的详细信息。我们发现就一个“kcvfh”，OK直接查看这个吧。
BBED> map
File: /data/oracle/oradata/bops10g/system01.dbf (1)
Block: 1                                     Dba:0×00400001
————————————————————
Data File Header

struct kcvfh, 676 bytes                    @0

ub4 tailchk                                @8188

print出来的内容太多，我做了删剪，留下我们有用的内容。
BBED> print kcvfh
struct kcvfh, 676 bytes                     @0
…………………………
struct kcvfhckp, 36 bytes                @484
struct kcvcpscn, 8 bytes              @484
ub4 kscnbas                        @484      0×000748bf–SCN的低位
ub2 kscnwrp                        @488      0×0000–SCN的高位
ub4 kcvcptim                          @492      0×2ea86f92 –最后一次checkpoint time
ub2 kcvcpthr                          @496      0×0001

………………………………
ub4 kcvfhcpc                             @140      0×0000007f—checkpoint count
ub4 kcvfhrts                             @144      0×2ea86844
ub4 kcvfhccc                             @148      0×0000007e
–oracle 一个TBS最多30个字符，通过BBED ，我们发现这里是定长的
text kcvfhtnm[0]                         @338     S
text kcvfhtnm[1]                         @339     Y
text kcvfhtnm[2]                         @340     S
text kcvfhtnm[3]                         @341     T
text kcvfhtnm[4]                         @342     E
text kcvfhtnm[5]                         @343     M
text kcvfhtnm[6]                         @344
text kcvfhtnm[7]                         @345
text kcvfhtnm[8]                         @346
text kcvfhtnm[9]                         @347
text kcvfhtnm[10]                        @348
text kcvfhtnm[11]                        @349
text kcvfhtnm[12]                        @350
text kcvfhtnm[13]                        @351
text kcvfhtnm[14]                        @352
text kcvfhtnm[15]                        @353
text kcvfhtnm[16]                        @354
text kcvfhtnm[17]                        @355
text kcvfhtnm[18]                        @356
text kcvfhtnm[19]                        @357
text kcvfhtnm[20]                        @358
text kcvfhtnm[21]                        @359
text kcvfhtnm[22]                        @360
text kcvfhtnm[23]                        @361
text kcvfhtnm[24]                        @362
text kcvfhtnm[25]                        @363
text kcvfhtnm[26]                        @364
text kcvfhtnm[27]                        @365
text kcvfhtnm[28]                        @366
text kcvfhtnm[29]                        @367
………………………………

这4个offset的位置内容，文档上是这样说的：

Oracleconsiders four attributes of this data structure when determining if a datafile is sync with the other data files of the database:

（1）kscnbas (at offset 484) - SCN of last change to the datafile.

（2）kcvcptim (at offset 492) -Time of the last change to the datafile.

（3）kcvfhcpc (at offset 140) - Checkpoint count.

（4）kcvfhccc (at offset 148) - Unknown, but is always 1 less than thecheckpoint point count.

oracle主要通过这4个来判断一致性，至于中文说明，我也写在上面了。

接下去，我们看看坏掉的wt-tbs01.dbf的信息：

wt_tbs.dbf
struct kcvfhckp, 36 bytes                @484
struct kcvcpscn, 8 bytes              @484
ub4 kscnbas                        @484      0×000747a5
ub2 kscnwrp                        @488      0×0000
ub4 kcvcptim                          @492      0×2ea86f03
ub2 kcvcpthr                          @496      0×0001
union u, 12 bytes                     @500
struct kcvcprba, 12 bytes          @500
ub4 kcrbaseq                    @500      0×00000004
ub4 kcrbabno                    @504      0×00000019
ub2 kcrbabof                    @508      0×0010
**********************
ub4 kcvfhcpc                             @140      0×00000007
ub4 kcvfhrts                             @144      0×2ea86844
ub4 kcvfhccc                             @148      0×00000006

好，484，492，140，148直接修改就好了。
/**************
484
****************/
ub4 kscnbas                        @484      0×000747a5-> 0×000748bf–> bf487400

set offset 484
modify /x bf48
set offset 486
modify /x 0700

/**************
492
******************/
ub4 kcvcptim                          @492      0×2ea86f03->0×2ea86f92 –>926fa8ea

set offset 492
modify /x 926f
set offset 494
modify /x a82e

/**************
140
******************/

ub4 kcvfhcpc                             @140      0×00000007->0×0000007f–>7f000000

set offset 140
modify /x 7f00
set offset 142
modify /x 0000

/**************
148
**************/
ub4 kcvfhccc                             @148      0×00000006->0×0000007e->7e000000

set offset 148
modify /x 7e00
set offset 150
modify /x 0000

最后做下checksum，就OK了

BBED> sum dba 5,1 apply
Check value for File 5, Block 1:
current = 0×554c, required = 0×554c
接下去就简单了，重建控制文件，数据库OPEN RESETLOG搞定

@>startup nomount;
ORACLE instance started.

Total System Global Area  838860800 bytes
Fixed Size                  2087608 bytes
Variable Size             494929224 bytes
Database Buffers          335544320 bytes
Redo Buffers                6299648 bytes
@>CREATE CONTROLFILE REUSE DATABASE “orcl” RESETLOGS  NOARCHIVELOG
2      MAXLOGFILES 5
3      MAXLOGMEMBERS 5
4      MAXDATAFILES 100
5      MAXINSTANCES 1
MAXLOGHISTORY 292
6    7  LOGFILE
8    GROUP 1 ‘/data/oracle/oradata/orcl/redo101.log’  SIZE 10M,
9    GROUP 2 ‘/data/oracle/oradata/orcl/redo201.log’  SIZE 10M,
10    GROUP 3 ‘/data/oracle/oradata/orcl/redo301.log’  SIZE 10M
11  — STANDBY LOGFILE
12  DATAFILE
13    ‘/data/oracle/oradata/orcl/system01.dbf’,
14    ‘/data/oracle/oradata/orcl/undotbs01.dbf’,
15    ‘/data/oracle/oradata/orcl/sysaux01.dbf’,
16    ‘/data/oracle/oradata/orcl/users01.dbf’,
17    ‘/data/oracle/oradata/orcl/wt_tbs01.dbf’
18  CHARACTER SET US7ASCII
19  ;

Control file created.

@>RECOVER DATABASE USING BACKUP CONTROLFILE
ORA-00279: change 477375 generated at 05/09/2012 01:49:06 needed for thread 1
ORA-00289: suggestion : /data/oracle/arch/orcl/1_4_782784012.arc
ORA-00280: change 477375 for thread 1 is in sequence #4

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
cancel
Media recovery cancelled.
@>ALTER DATABASE OPEN RESETLOGS;

Database altered.

小小广告下，我的微薄（ )，http://weibo.com/vogts 有问题可以直接找我一起探讨下,Thanks！

高可用：可用性是运维的根本，我们不管做什么事情，都要把可用性放在第一位。
高性能：对性能的关注是我们一直坚持、做的最好的一面，仍需要继续做到极致。
可扩展：也就是最适合的，易部署，可线形透明伸缩。
数据存储：不只是关注某个数据库本身，是基于对各种最先进的数据存储技术的精深理解，提供最专业的服务

说白了，只要你有几年JAVA WEB开发经验，对数据库内部技术有浓厚兴趣，都欢迎加入。
在这里，你可以与国内顶级DBA一起切磋数据库问题，可以对海量数据进行分析与挖掘，掌握快速发现系统性能瓶颈的方法。

职位发展方向：开发技术、数据库技术、运维经验思想三位一体的牛人。

简历请发给： zhengsheng.yezs@alibaba-inc.com

最近发现市场上竟然真的有这样的产品，据说卖的很不错，主要应用在移动电信领域，了解了一下，基本知道其中的做法，里面的有些想法还是蛮有意思的，跟大家分享一下:

其实原理也很简单，他们是解析了oracle redolog 文件，不过他们解析的是变化的块号，然后根据变化的块号，到主库去将文件中的数据块读取出来，最后覆盖到standby 中对应的数据文件（standby　一直是处于open read only 状态）。

这样覆盖后，就有个需要处理的地方

1 . 如果原先有一个数据块被cache ，那么覆盖了数据文件后，为了得到最新的数据，就需要程序定期去刷新buffer cache ，从而才能让oracle 去读取最新的数据块。

2. 由于程序去定期刷新buffer cache ，那么如果发出一个select 查询，就会出现有些块在内存中数据已经是比较老的，有些数据块直接从文件中读取读取的是最新的数据块，这样就会造成数据不一致的情况。 那这种情况怎么去处理呢 ？ 是否记得oracle 中有个语法 select * from table as scn of XX ? 让oracle 自己去查询某个时间点的数据，自己去构造一致性读取。但是这样就会造成另外一个问题，这个SCN 号如何去取呢 ？ 那么很简单，我们只要select min(scn) from x$bh where scn > 我上次flush buffer cache 时间点的SCN, 得到buffer cache 中最小数据块的SCN 号，然后发出一个命令，以小于buffer cache 中最小SCN 号的方式去查询，那么就可以查到一致的数据。比如buffer cache 中数据块最小的SCN 号 是100 ，那么我们select * from table as scn of 95 ,那么肯定数据查出来在那个时间点是一致的。 这样就带来另外一个问题，是不是需要让应用去改造sql 呢，每个select 都要加上scn 号去查询？ 这边就用了一个技巧，先得到全局SCN 号在SGA 中的内存地址，然后用程序去修改成我们需要的SCN 号，这样oracle 去查询的时候总是会去构造一致性查询

好了，解决了上面的问题，还有一个问题就是DDL 引起的share pool 的变化，这就需要程序去定期刷新shared pool ,虽然我一直认为这会存在问题，但是据卖这款产品说，客户反映用的还蛮好

看的出来，上面做的东西在OLTP 中不太好用，跟oracle 11g 的active standby 也存在差距。但是如果用在报表系统或者给DW 批量拉数据，还是非常不错的。在保证有备份的同时，又能给用户提供服务，最大化利用了资产

• 去关系型，NoSQL是王道
• NoSQL靠边站，关系型才是王道
• 以关系型为核心，NoSQL为补充

三种意见中前面两种观点较为极端，都是“非对即错”的选择，当然也有更为理性的第三种方案。

如果作为开发人员，从我目前所了解的信息来看，主要还是倾向于第一种思路。因为在他们看来，分布式的 NoSQL 系统是一个非常美的架构，不仅仅解决了扩展性的问题，同时也解决了可靠性问题，同时还可以让程序开发免去关系型模型的约束，不选择他才是傻子呢！

从我个人的角度来看，我目前更倾向于第三种思路，至少在现阶段是如此。

Why？

但是如果是从运维的角度出发，所考虑的风险点可能完全不一样。作为一个存储数据的核心组件，在需要对其数据进行人工订正维护的时候是否方便操作？在需要抽取其中某部分数据到线下给开发/测试部门使用的时候是否方便？最重要的是，当他整个 Crash 之后我们可以怎么恢复？当我们面对这些问题的时候，我们是否有合适便利的手段来避免或者解决？

确实，理念很完美，架构很完美，但目前的NoSQL产品的实现是不是真的也如此完美呢？我想没有哪个产品敢拍着自己的胸脯说他们的产品不会Crash，就像没有厂商向我们保证他们的硬件在达到标称的使用寿命之前不会损坏一样。既然存在整个 Crash 的可能，那就必须考虑如何应对。我们不能只是考虑这个听上去完美的分布式系统在某个节点 Crash 之后可以很好的”自愈”，不能只考虑当目前整个集群资源达到瓶颈之后仅仅只需要在线增加一个节点就可以”自我完成负载/数据重分布”。我们还需要考虑他的整体可靠性，还需要考虑更为恶劣的环境更为残酷的场景下，他是否还能生存。

关系型数据库在刚开始产生的时候，同样面临了各种各样的问题，同样受到过大量的质疑。但是，当他在风风雨雨中走过了这么多年之后，通过不断的完善和适应，不论在灾难恢复方面还是在可操作性和可维护性方面都做了大量的工作。当然，在这么多年的市场需求下，也培养出了大量的专业技术人员。但 NoSQL 发展到现在，才经历了很短的时间，缺少在恶劣环境下的磨炼，缺少复杂环境下的检验，更缺少有丰富经验的专业技术人员。在这种情况下，你还敢轻易决定将一个公司最为核心的资本（数据）轻易从关系型数据库中迁移出来吗？

当然，我们并不一定要一个完美的产品，就像我们无法让我们自己成为一个完美的人一样。但我们必须清楚一个产品的可能存在的风险和缺陷，并且清楚如何做能避免这些风险和缺陷，同时还要让我们自己有能力避免这些风险和缺陷。只有在这样的前提下，我们才会在比较重要的场景下使用。但要积累这些经验，积累这些信任，培养专业技术人员，都需要一定的时间。

所以在我个人看来，在近几年，NoSQL 暂时还不可能成为数据管理软件领域的主角，仍然只能作为特定场景下的数据存/取解决方案的补充，即使在互联网行业也是如此。至于在未来，比如五年十年以后会是什么样子，我就无法预测了。

注：文中观点仅代表个人，基于个人目前的认知，欢迎大家拍砖！

原文出自：  NoSQL or Relational ?

• 通过在 Master 和 Slave 之间增加一层复制代理服务
• 多个线程连接上多个 Master 上请求 Binlog（完全模拟 Slave 上的IO线程）
• 多个线程连接上单个 Slave 实例，直接以类似于应用程序的方式并行应用 Binlog中的Event（部分模拟Slave 上的SQL线程）
• 由于很清楚业务场景，在应用线程方面可以在一些特定规则约束下实现并行应用以改善 Slave 端延时

由于 MySQL 开源的特性，实现上述功能其实很简单，还可以保持原生 MySQL 不会被动任何手术即可完成我们的需求，看来是该动手的时候了。

BTW： 我的需求中，各个 Master 中的数据是不会有任何重叠的。

原文出自： 单个MySQL Instance 接多个 Master 的一点想法

内容方面，前面的部分可能有不少朋友以前有看到过，可能是听我介绍过，也有可能本身自己就对这些架构很了解。无所谓，只要能对一少部分人有用，那也欣慰。不过，最后两页 PPT 的内容，我想肯定没有人在其他渠道见过，因为这两张图片是我第一次在公开场合展示。

废话少说，上 PPT 吧，呵呵！

原文出自：OOW 分享的 PPT

optimal:当驱动结果集生成的hash表全部可以放入PGA的hash area时，称为optimal，大致过程如下：
1.先根据驱动表，得到驱动结果集
2.在hash area生成hash bulket，并将若干bulket分成一组，成为一个partition，还会生成一个bitmap的列表，每个bulket在上面占一位
3.对结果集的join键做hash运算，将数据分散到相应partition的bulket中，当运算完成后，如果键值唯一性较高的话，bulket里的数据会比较均匀，也有可能有的桶里面数据会是空的，这样bitmap上对应的标志位就是0，有数据的桶，标志位会是1
4.开始扫描第二张表，对jion键做hash运算，确定应该到某个partition的某个bulket去探测，探测之前，会看这个bulket的bitmap是否会1，如果为0，表示没数据，这行就直接丢弃掉
5.如果bitmap为1，则在桶内做精确匹配，判断OK后，返回数据

这个是最优的hash join，他的成本基本是两张表的full table scan，在加微量的hash运算

onepass
如果进程的pga很小，或者驱动表结果集很大，超过了hash area的大小，会怎么办？当然会用到临时表空间，此时oracle的处理方式稍微复杂点需奥注意上面提到的有个partition的概念，可以这么理解，数据是经过两次hash运算的，先确定你的partition，再确定你的bulket，假设hash area小于整个hash table，但至少大于一个partition的size，这个时候走的就是onepass
当我们生成好hash表后，状况是部分partition留在内存中，其他的partition留在磁盘临时表空间中，当然也有可能某个partition一半在内存，一半在磁盘，剩下的步骤大致如下：
1.扫描第二张表，对join键做hash运算，确定好对应的partition和bulket
2.查看bitmap，确定bulket是否有数据，没有则直接丢弃
3.如果有数据，并且这个partition是在内存中的，就进入对应的桶去精确匹配，能匹配上，就返回这行数据，否则丢弃
4.如果partition是在磁盘上的，则将这行数据放入磁盘中暂存起来，保存的形式也是partition，bulket的方式
5.当第二张表被扫描完后，剩下的是驱动表和探测表生成的一大堆partition，保留在磁盘上
6.由于两边的数据都按照相同的hash算法做了partition和bulket，现在只要成对的比较两边partition数据即可，并且在比较的时候，oracle也做了优化处理，没有严格的驱动与被驱动关系，他会在partition对中选较小的一个作为驱动来进行，直到磁盘上所有的partition对都join完

可以发现，相比optimal，他多出的成本是对于无法放入内存的partition，重新读取了一次，所以称为onepass，只要你的内存保证能装下一个partition，oracle都会腾挪空间，每个磁盘partition做到onepass

multipass
这是最复杂，最糟糕的hash join，此时hash area小到连一个partition也容纳不下，当扫描好驱动表后，可能只有半个partition留在hash area中，另半个加其他的partition全在磁盘上,剩下的步骤和onepass比价类似，不同的是针对partition的处理
由于驱动表只有半个partition在内存中，探测表对应的partition数据做探测时，如果匹配不上，这行还不能直接丢弃，需要继续保留到磁盘，和驱动表剩下的半个partition再做join，这里举例的是内存可以装下半个partition，如果装的更少的话，反复join的次数将更多，当发生multipass时，partition物理读的次数会显著增加

从10G开始，oracle引入了时间模型，我们可以从oracle的角度来看CPU的使用程度
先说说几个概念
db time:oracle数据库消耗的时间，这个范围比较大，包括了CPU使用，等待IO子系统返回，网络处理等
db cpu：指oracle单纯消耗CPU，做CPU运算的时间，关于IO,网络的等待都不在这个范围内，用它来统计真实CPU的消耗比较准确
CPU TIME:这个是我取的名字，表示CPU能给你提供的最大时间，比如你有4个cpu/core，那么1小时内，CPU TIME就是4X60分钟

我通过一个测试脚本来看看oracle里面关于CPU时间的统计

#killcpu.sh
#!/bin/sh
export ORACLE_SID=innodb
export ORACLE_HOME=/opt/oracle/products/11.2.0

$ORACLE_HOME/bin/sqlplus /nolog <<_kof_
connect iops/iops@innodb
declare v_count pls_integer := 0;
begin
        for x in 1..400000000 loop
                for d in 1..400000000 loop
                        for c in 1..400000000 loop
                                v_count :=mod(c, mod(x,d));
                        end loop;
                end loop;
        end loop;
end;
/
_kof_

测试机器是Intel(R) Xeon(R) CPU E7530的4C6核 CPU，虚拟出来总共是48个core
killcpu采用24并发，48并发，60并发做测试，每个10分钟，通过statspack收集信息，按照上面的公式，我们的cpu time=10min*60 * 48core=28800秒
最终结果如下(时间单位都是秒)：

从结果可以看出：
24并发，oracle使用了24个core，整体的CPU占用率在50%，load在24，非常准确，此时db time基本和db cpu一致，因为你干的所有事情，都是在CPU上
48并发，oracle使用了48个core，CPU使用率达到100%，oracle在多cpu环境下对资源的利用确实很高，此时db time，db cpu,cpu time一致了，CPU在满负荷运转
60并发，这个时候会发现，db cpu没变，因为CPU已经耗尽，没得涨了，db time现在已经远大于cpu time和db cpu，这说明我们有一部分的程序根本抢不到CPU，进入了
等待,load也超过了core数量，达到57

通过db cpu/db time，我们可以看出这个数据库是否是CPU使用很重的应用，比如大量的运算，latch争用等，
如果是一个IO很重的应用，会发现db cpu站的比例会很小

IO负载统计

IO表现在两个方面，IOPS和吞吐量，我们OLTP系统，一般比较关心IOPS，及每个IO的响应时间，
以前针对IOPS统计，我们一直是按照statspack的physical reads+physical writes来统计，这个是很不准确的
按照文档的解释：
physical reads：Total number of data blocks read from disk
这个是按照block读取的数量来统计的，oracle的IO种类有很多，如果是scatter read或者parallel read，一个IO会读取多块的，
这样计算IOPS会偏大，重新调整后，发现统计出来的曲线和从存储段观察的比较吻合

9I:
–IOPS&MBPS
select sum(iops) as iops,sum(mbps) as mbps
from (
select sum(phyrds + phywrts) as IOPS,
sum(phyblkrd + phyblkwrt) as MBPS
from (select a.phyrds,a.phywrts,a.phyblkrd * b.block_size / 1024 / 1024 as phyblkrd,a.phyblkwrt * b.BLOCK_SIZE / 1024 / 1024 as phyblkwrt
from v$filestat a,v$datafile b
where a.file# = b.file#)
union all
select sum(decode(name,’redo writes’,value,’0′)) as IOPS,
sum(decode(name,’redo size’,value,’0′)) / 1024 / 1024  as MBPS
from v$sysstat where name in( ‘redo writes’,'redo size’));

10G/11G
–IOPS&MBPS
select sum(decode(name,’physical read IO requests’,value,’physical write IO requests’,value,0)) as iops,
sum(decode(name,’physical read bytes’,value,’physical write bytes’,value,0)) / 1024 / 1024 as mbps
from v$sysstat
where name in (’physical read IO requests’,'physical write IO requests’,
‘physical read bytes’,'physical read total bytes’,
‘physical write bytes’,'physical write total bytes’,'physical read total IO requests’,'physical write total IO requests’
);

最近将这些统计指标做进了监控系统，看看效果怎么样

很多朋友听闻此事后都向我道贺，也有很多朋友提出疑问： Oracle ACE 到底为何物？

Oracle ACE 程序主要是 Oracle 公司为了奖励使用推广Oracle公司某个领域产品的技术专家们所做的贡献而设立的一种荣誉机制。目前，除了通过业内知名人士举荐并由 Oracle 公司的人提名最终经过 ACE 程序审核小组评审之外，无法通过认证考试或者是其他途径获得。

目前国内共有 16 位技术专家获此荣誉，分别分布在6个技术领域，如下：

• Database Management & Performance：5人
• Database App Development：5人
• Middleware & SOA：4人
• Applications & Apps Technology：1人
• MySQL：1人

其中 MySQL 领域目前国内就我一个人（希望在未来能够有越来越多的战友们能够加入这个行列），全球也只有4位。能够获此殊荣，确实非常开心，这是对我个人在这个技术领 域内的认可。当然，这也离不开我所在的公司为我提供的成长平台，离不开所在Team的各位同事给我的帮助。同时，也希望国内有更多的技术专家能够获得 ACE 称号。

原文出自： Sky.Jian – i Sky000

话说 Oracle ACE 这回事儿