Tag Archives: DBA

可用性级别与停机时间

一个网站 99.99% 的可用性是什么概念 ? 每年停机时间不能超过 53 分钟, 平均下来, 每个季度 13 分钟多一点点. 其他常说的几个级别见下图:
网站的维护级别
对于国内的网民来说, Google 的可用性应该是最低的. 从用户的角度上看, 恐怕连 95.0% 都达不到. 当然这不是 Google 的错.
IM 工具的可用性程度也不高, 比如 MSN Messenger 经常的掉线、消息发不出去;虽然用户也怨声载道, 但是没看到谁因为登陆不上 MSN Messenger 而转用别的 IM 的。个人估计微软的 MSN 对于普通用户来说可用程度也就是比 95.0% 好一点.
Web 2.0 的站点可用级别也比较低的. 可用级别最高的或许能达到 99.9%. Del.icio.us 去年就连续断电了几次, Bloglines 出来过多次水管子工，而豆瓣也出现过几次停机故障. 因为用户黏度在那里, Web 2.0 站点还真不用担心那么一会儿停机会丢失用户的问题, 除非真是拿到了花不完的风险投资，否则投入大笔费用来提高一个 “9” 的可用能力没有太大必要。
电子商务站点应该是很讲究可用性级别的, 联机事务处理能力要求相对较高, ‘1 秒钟几十万上下’, 提高可靠性的手段无非是高投入–通过大量软件硬件的冗余、更多的技术更为精湛的维护人员.
需要什么样的维护级别 ? 当然不是拍脑袋想出来的, 我想任何一个理性的公司都应该考虑投入产出比, 不考虑实际应用类型而盲目的追求高可用性不可取.
前几天和朋友聊天说起来,

A: "你上个季度系统的稳定性怎么样 ? "
B: "四个 9 阿" 
A: "这么强?"
B: "嘿嘿, 虽然没啥防范措施, 凑巧没有宕机而已"

把这个当作笑话吧…

–EOF–

更新：纳斯达克的可用性 99.98 ，基本上是微软软件构建的。eBay 可用性，披露出来的数据是 99.94%.

对 Oracle DBA 最有帮助的一本书

在论坛上作了一个小小的调查: 大家说说看过的最有帮助的 Oracle 图书是什么 ? . 从参与的讨论中得到的一个有趣的结论: Oracle Database Concept 是对大多数 DBA 来说最有用的图书. Oracle 的概念手册是随版本号更新的. 执笔者是 Michele Cyran , 对内容有贡献者大约还有几十个人.
很多人都不掩饰对这本概念手册的喜爱, 有的 DBA 甚至仔细阅读过数遍。重剑无锋，大巧不工。以前和朋友聊天的时候说起过 “DBA 日常工作中可能 99% 的场景都只需要最基本的知识”, 问题是: 最基本的知识是否掌握了 99% ?
这本书如果有影印版的话估计会是一本畅销书. Tom 的 Expert one-on-one Oracle 也被很多人推崇.
–End.

的确没有那么多”迷信” [DBA工作备忘]

昨天拜读了刘润的“不要搞封建迷信活动”，深有感触．前一段时间我在处理 Data Guard 的时候, 遇到过一件怪事. “怪现象一定有原因的”．果然, 经过仔细分析之后, 果然发现并不是灵异现象. 凡事皆有因果.
情景描述:
在一个机器上建立两个同一数据库的 Data Guard. 其中一个 Data Guard 已经建立,数据文件放在 foo 目录下.现在准备建立第二个 Data Guard, 数据文件放在 fooback 下. 初始化参数已经设置:

*.db_file_name_convert='/opt/oracle/oradata/foo/','/opt/oracle/oradata/fooback/'

其他的设置略. 用第一个 Data Guard 备份的控制文件, 启动第二个实例, 进行恢复. 开始正常, 恢复了几个文件之后,遇到如下错误:
skipping datafile 56; already restored to file /opt/oracle/oradata/fooback/user_log_04.dbf
skipping datafile 57; already restored to file /opt/oracle/oradata/fooback/user_log_05.dbf
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00058 to /opt/oracle/oradata/foo/foo_note_06.dbf
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 03/24/2006 11:32:48
ORA-19504: failed to create file “/opt/oracle/oradata/foo/foo_note_06.dbf”
ORA-27086: skgfglk: unable to lock file – already in use
IBM AIX RISC System/6000 Error: 13: Permission denied
Additional information: 8
Additional information: 553070
已经作了数据文件名字映射,　在第 58 个文件映射失败(应该是 fooback 目录下的文件,又跑到 foo 上去恢复了!) 怪哉!
进入第一个实例, 查询文件名字,正常．进入第二个实例, 查询文件名字, 前面 57 个都是 fooback 目录下的, 第 58 个就变成了 foo . 难道是遇到了 Bug 么 ? 为什么是 58 ?
折腾了许久, 针对这个58 ,我去查以前的数据库变动, 发现这个文件,是第一个 Data Guard 建立之后我第一次添加的数据文件.
oops, 我用的这个控制文件有问题!! 如果只在一个机器上建立一个 standby ,那么用其他 standby
备份出来的控制文件, 并且不修改文件名字映射的话, 不会出现该问题的. 而第一个 Standby 的控制文件,只从 Primary DB 控制文件带来 57 个数据文件的信息.所以, 在 58 个失败.　而 Oracle 的 Data Guard 文档中建议的标准做法是从 Primary DB 取控制文件.
Bug ,这是一个 DBA 甚至是所有 IT 工程师最容易”迷信”的地方. 破除迷信, 从现在开始.　

继续阅读 →

从一个DBA的角度读《Spring in Action》(中文版)

同事中的几位大侠翻译了《Spring in Action》, 今天公司组织买了一些，”抢”到了一本。书是刚刚上市不久的–还热乎的呢 :)
有的同事看我也看 Java 方面的书，可能觉得比较好笑。其实，作为一个 DBA，如果要有效地与开发人员的沟通, 不熟悉系统中所用的框架, 就会吃力许多, 刚开始到目前的团队中工作的时候也偶尔会闹笑话. 自己想了解一些 J2EE 框架基本概念的念头也有好久了，正好趁着有资料，学习学习。
今天匆忙读了第四章”征服数据库”, 有几点给我留下了比较深的印象.
1) 数据访问异常的划分很清晰; 应用排错的时候很容易定位到具体问题;
2) 通过一定的设置, 任何一个 SQL 都能够输出到 Log 里, 对于 DBA 的优化调试非常有帮助;
3) 对 DAO 层数据库访问很容易隔离; 一部分程序员可以不用太关心数据库层, 而把这一部分的诸如效率、稳定性交给 DBA 处理;　也的确如书中所说简化了应用系统的复杂度并能提高开发效率;
4) 可重用的 DAO. 对于 DBA 来说, 应该注意因为 DAO 重用有的时候可能会带来一些多余的 SQL 解析. 在 Tuning 的时候需要注意。
我对 Java 一窍不通, 有理解不对的地方请读者指正!

继续阅读 →