Oracle MySQL NoSQL DBA|数据管理,架构,监控与性能优化 --- NinGoo.net
NinGoo's blog
  • 初略的翻了一下《1984》,直觉的浑身冷汗。 1 day ago
  • 其实更愿意坚持,有时候也是不得以。 @mujiang 1 day ago
  • 淘宝第一台小型机上的核心库的即将下线,完成了其五年的历史使命。接下来会有越来越多小型机存储的下线,pc化,水平化,可扩展高可用的趋势,不可阻挡。 2 days ago
  • 卓越的书,昨天就已经收到了。但是今天才收到卓越的邮件,说库房已经安排发货,预计明天可以送达,请您耐心等待、保持电话畅通并注意查收。这是什么系统啊,囧。 2 days ago
  • 昨天在卓越下单买的几本书上午就送到了,不到24小时,效率不错。 3 days ago

PostgreSQL简介

上个周末,无聊的时候关注了一下PostgreSQL。第一次尝试去安装PostgreSQL,还是好几年前的事了,那是8.0版本刚出来,终于开始原生的支持windows了,所以在自己电脑上折腾了一个。不过那时候也仅限于安装了一次而已,甚至psql的命令行都不知道怎么用。

同样作为开源关系型数据库,MySQL在这几年获得了更多的关注。大量的互联网公司都基于MySQL来构架系统,也导致MySQL DBA开始火热,一大堆年轻有为的同学投入到其中,渐成燎原之势。MySQL数据库火热了,MySQL AB公司却被sun收购,现在又随着sun要投入Oracle的怀抱,而且欧盟已经无条件批准这个收购,只剩下中国和俄罗斯,大局已定。作为商业数据库的绝对老大,Oracle的这次收购,让MySQL的支持者感到了威胁,其创始人甚至发起了一场保护MySQL(有墙),阻击Oracle收购的运动。

这也是PostgreSQL的机会,最近PostgreSQL的开发节奏很快,8.5已经连续出到了alpha3版,在这个版本中,最吸引我的是hot standby,类似于Oracle11g的active data guard,hot standby也可以在恢复的同时提供读服务,而以往版本,PostgreSQL的物理备库warm standby,则只能处于恢复状态,一旦open,则需要重做,比较痛苦。PostgreSQL的很多特性,都和Oracle相当的类似,甚至有一家商业化的公司EnterpriseDB,在致力于将PostgreSQL打包,使得应用程序从Oracle迁移到PostgreSQL更方便,据说80%的Oracle应用代码甚至不需要做修改就能在PostgreSQL运行。因此,我在twitter上说,如果PostgreSQL在人机交互的工具和配置部分,能够更加友好一点,完全是一个影子版本的Oracle。

PostgreSQL也支持mvcc多版本一致性控制。不过其实现的机制,和innodb的方式比较像,而和Oracle的不一样。Oracle是将变化的前映像记录到单独的undo段中,而PostgreSQL则只是将前映像(Tuples)上做个标记,如果是delete,则相当于是逻辑删除,实际的数据还是在原来的段中,如果是insert,相当于先delete,再insert,而且会在原来的记录上加一条指向新记录的指针,形成一个链表,查询的时候需要沿着这个链表找到一致的数据。这样会造成一个问题,一段时间以后,dml操作使得数据段和索引段中都有大量的前映像信息存在,会严重影响数据查询的效率。PostgreSQL的mvcc的这种实现方式,带来的一个好处是回滚非常快,只需要修改前映像上的几个标志位即可,而不像oracle需要从undo段将前映像再复制回来。但是,这种方便回滚,却会损失查询性能的设计思路,真的比较诡异。PostgreSQL中有一个专门用来清理这些旧版本数据的程序,叫做vacuum。在以前的版本中,需要定期执行vacuum来优化数据存储结构。这对于DBA来说,无疑是一件痛苦的事情。直到8.1版本,引入了autovacuum,系统可以自动来进行这些清理工作,终于人性化了一点点。

在8.3版本,引入了一个新的特性HOT(Heap Only Tuples),主要的目的是努力避免update造成的性能低下的问题。其实这个HOT,说白了很简单,对于update,要实现mvcc,其机制还是一样的,区别在于select,在沿着链表找一致性数据的过程中,如果发现这个检查过的版本已经没有任何事物在引用了,就会顺便把清理工作做掉,而不是像以前要等vacuum来做。因此这会加大一点select的压力,但前人栽树,后人乘凉,接下来需要访问这些数据的其他select就会快很多了,这和Oracle的延迟块清除其实有些类似的,当然两者的设计目的并不一样。

tbstat:实时监控数据库统计状态的小工具

用perl写了一个简单的工具,用于实时查看数据库的统计状态信息,展现信息主要来源于Oracle数据字典中v$systat和v$system_event。写这个工具的初衷,是因为目前我们对于数据库的监控,更多的是分钟级别抽样的数据来绘制的图形,粒度相对还比较粗,有一些比较深的问题,需要更加细粒度的数据。而如果把监控的粒度做到秒级,则收集的数据量就会非常大,因此需要一个平衡,平时采用分钟级别的抽样数据已经足够用于预警,而秒级的则用于某个具体问题的分析。

当前tbstat功能还比较简单,类似于iostat/vmstat等os工具,tbstat可以通过指定抽样间隔和抽样次数,来循环抓取Oracle的统计状态信息。tbstat支持三个参数 -i 表示间隔时间 -c 表示循环次数 -n 表示需要查看的统计信息的名字(使用前后%的like来查询)

  • tbstat -i 2 -c 10 表示间隔时间2s,循环次数10次,展示经过人工筛选的36项统计信息
  • tbstat -i 2 -c 10 -n parse 表示间隔时间2s,循环次数10次,展示所有名字包含parse的统计信息
  • tbstat -i 2 -c 10 -n all 表示间隔时间2s,循环次数10次,展示所有不为零的统计信息

也可以使用简化的参数输入方法,第一位表示间隔时间,第二位表示循环次数,第三位表示统计信息名。直接敲入tbstat,则默认的参数为间隔时间10s,次数无限,经过挑选过滤的一些常用的v$sysstat中的统计信息。如果name参数传入的值是event,则展示v$system_event中的等待事件的信息。

$tbstat 1 0
--------------------------------------------------------------------------
-- tbstat v0.3.3 --- a tool for oracle system statistics and event.
-- Powered by NinGoo.net
--------------------------------------------------------------------------                      

               CPU used by this session:     40                       CR blocks created:       5
        DBWR checkpoint buffers written:    569                  DBWR undo block writes:      64
 bytes received via SQL*Net from client: 314297        bytes sent via SQL*Net to client: 2761660
  cleanouts only - consistent read gets:      4                         consistent gets:   48855
                       db block changes:   2122                           db block gets:    3714
                       enqueue requests:    900                           enqueue waits:       7
                          execute count:   3145                   free buffer requested:    1402
         index crx upgrade (positioned):      3            index fast full scans (full):       0
                 leaf node 90-10 splits:      0                        leaf node splits:       0
                      logons cumulative:      1                  parse count (failures):       0
                     parse count (hard):      0                          physical reads:    1546
          physical reads cache prefetch:      0                         physical writes:     603
                              redo size: 618436                         redo synch time:      16
                      redo synch writes:    181                         redo write time:      15
                            redo writes:    174   rollbacks only - consistent read gets:       0
                           sorts (disk):      0                          sorts (memory):     259
              table scans (long tables):      0              table scans (short tables):       9
                  transaction rollbacks:      0                            user commits:     182
$tbstat 1 0 event
-------------------------------------------------------------------------------
-- tbstat v0.3.3 --- a tool for oracle system statistics and event.
-- Powered by NinGoo.net
-------------------------------------------------------------------------------              

                   Event Name:   waits   time                       Event Name: waits   time
--------------------------------------------------------------------------------------------
      LGWR wait for redo copy:       1   0.01    SQL*Net more data from client:   151  19.95
  SQL*Net more data to client:    1218   0.01                buffer busy waits:     2   0.01
  control file parallel write:       1   0.51     control file sequential read:     1   0.26
                cursor: pin S:       0   0.00          cursor: pin S wait on X:     0   0.00
        db file parallel read:       0   0.00           db file parallel write:     0   0.00
       db file scattered read:       0   0.00          db file sequential read:  2040   3.43
             direct path read:     269   0.71            direct path read temp:     0   0.00
            direct path write:      23   0.26           direct path write temp:     0   0.00
         enq: CF - contention:       0   0.00             enq: HW - contention:     7   9.00
         enq: SQ - contention:       0   0.00     enq: TX - allocate ITL entry:     0   0.00
   enq: TX - index contention:       0   0.00    enq: TX - row lock contention:     0   0.00
                   latch free:       0   0.00      latch: cache buffers chains:     0   0.00
         latch: library cache:       0   0.00              latch: redo writing:     0   0.00
    latch: session allocation:       0   0.00               library cache lock:     0   0.00
             log buffer space:       0   0.00          log file parallel write:   145   0.60
     log file sequential read:     145   0.53       log file switch completion:     0   0.00
                log file sync:     147   0.78                os thread startup:     0   0.00
        read by other session:       0   0.00                   row cache lock:     0   0.00
       undo segment extension:       0   0.00

如果输入的name是精确匹配到只有一条统计信息的,会在后面打印出间隔时间内排名前10的sid的值。利用此功能,可以很方便的抓到造成某些统计信息异常的会话和SQL语句,会话和SQL信息是通过关联v$session来获取的。因此需要注意,如果统计信息对应的事件持续时间很短,从v$session里抓取到的sql可能并不是造成统计信息升高的罪魁祸首,但是sid一般来说还是准确的,因为应用采用的大多是连接池来连接数据库的,因此还是可以更具sid和machine信息来看看造成异常的是哪个具体的应用。

例如,全表扫描一般会导致physical reads cache prefetch等待事件,因此可以通过查看该事件对应的top sid来获得具体的语句,当然,不是所有的physical reads cache prefetch都是全表扫描导致的,因此对于获得的结果,还需要DBA根据具体情况做进一步分析:

$tbstat 1 0 'physical reads cache prefetch'
-------------------------------------------------------------------------------
-- tbstat v0.3.3 --- a tool for oracle system statistics and event.
-- Powered by NinGoo.net
-------------------------------------------------------------------------------
 physical reads cache prefetch:         526                             

              sid        value     %              machine         sql_id
       ----------  ----------- -----  ------------------- --------------
             2928          302  69.7               test11  79db58a3dg921
             4902           67  15.5               test71  79db58a3dg921
             4821           64  14.8               test33  3afdq50xt03ch
             4544            0   0.0               test54  3afdq50xt03ch
             1801            0   0.0               test06  79db58a3dg921
             2830            0   0.0               test12  79db58a3dg921
              898            0   0.0               test09  4n7675hwwcndc
             1031            0   0.0               test16  79db58a3dg921
              463            0   0.0               test04  3afdq50xt03ch
             1364            0   0.0               test08 cq749u66x06uj
             1408            0   0.0               test27  39rbqj3ck76w3
              722            0   0.0               test37  26hdkf07336uf

当然,tbstat只是一个用于抽取统计状态的小工具而已,如果要用于故障诊断,则还是要求DBA对于v$systat和v$system_event中各种统计和事件非常的熟悉。tbstat使用了DBD::Oracle以sysdba身份来连接数据库,因此需要为Perl安装DBI和DBD::Oracle模块,并且在数据库服务器本机上执行。如果你对于这个工具有兴趣,可以在这里下载源代码,使用过程中,如果有什么建议和需求,欢迎告诉我。

安昌古镇与乔波冰雪世界

元旦小假,第一天窝在家里,睡到自然醒,醒到自然睡,好好的放纵了一整天。2号一大早就赶到东站,出发去绍兴柯桥,计划去乔波冰雪世界滑雪,晚上则夜宿安昌古镇。

“乔波冰雪世界”是由前速滑世界冠军叶乔波女士倡导,清华科技园(启迪控股)投资建设,为我国唯一一家以室内滑雪为主、酒店(住宿、会议、餐饮、娱乐)为辅的综合性高档运动休闲场所。公司目标是成为我国运动与休闲产业的行业巨人。“绍兴乔波冰雪世界”是“乔波冰雪世界”在全国范围内的连锁企业之一,于 2009年10月初隆重开业。

公司坐落于国家AAAA级风景名胜“浙江省绍兴县鉴湖-柯岩风景区”内,南傍山北依水。项目总投资超过4亿元,建筑面积逾6万㎡。以大型室内滑雪馆、真冰溜冰场为主,并配套四星级会议休闲酒店,是一家集四季滑雪、溜冰、旅游、会议、餐饮、度假、娱乐为一体的综合性运动休闲场所。

结果11点多到的时候,人满为患,滑雪服等用具已经被先到的人一扫而空,无奈之下,只能临时改变计划,先去安昌,第二天再赶个大早过来,反正买的是全天票,正好可以多玩点时间。3号早上9点赶到,刚开门没几个人,玩的更high。

乔波冰雪世界

位于浙江省绍兴县安昌镇,始建于北宋时期,后因战乱,多次焚毁,又于明清时期重建,其建筑风格传承了典型的江南水乡特色,一依带水,古朴典雅,为浙江省重点历史保护地,其特产安昌腊肠、扯白糖远近闻名,具有水乡风情的水上婚礼也是别具特色。

安昌镇南靠柯桥,北邻杭甬高速公路,是一个具有千年历史的典型江南水乡古镇。境内现存白洋新石器时代越族先民遗址。相传大禹曾在镇东涂山娶妻成家。公元896年,钱镠奉唐王朝之命屯兵该地平董昌之乱,因命其乡为安昌。现存老街始建于明成化、弘治年间,数百年来,棉、布、米集散旺盛,蔚为越北大市重镇。抗战前夕尚有商号933家,是城区外市集之最。

安昌明清老街依河而建,全长1747米,至今保存完好。粼粼河水,石板街路,错落有致的翻轩骑楼,传统特色的店铺作坊,姿态各异的拱桥石梁,古老凝重的台门,幽深僻静的弄堂,风貌古朴典雅,无不体现出浓浓的水乡特色。

安昌也可以算是典型的江南水乡古镇,可惜河水已经是惨不忍睹,不知何年能重见清清河水沿街流,小小乌篷河上游的写意画卷了。到达的时候沿街人声鼎沸,熙熙攘攘,可以说无趣。唯一可让人怀念的,则是满街满门口挂的腊肠,确实名不虚传。
安昌古镇

安昌古镇

第二天从乔波冰雪世界出来已经是下午2点,精疲力尽的赶到轻纺城汽车站,不幸的是回杭州的班车最早的也要到5点多了。最后四个人一咬牙,决定倒公交车回去,先从柯桥坐到萧山,再在萧山转301到武林小广场,一路辗转,到家已是晚上6点。

2010,风生水起

无可奈何的,到了2010,无可奈何的,三十而立。无可奈何花落去,似曾相识燕归来,当年背得烂熟的诗,年少轻狂未解其意,而今嚼来一声叹息。

酸气倒完,生活继续。2009年,总体来说,虽有诸多不如意处,也做了不少事,有了不少改变。与己,逐步完成转变,从技术一线开始尝试学习团队管理;与事,数据库整体还算稳定,无奈Q4因为各种原因有点晚节不保,由此也可以看出任重道远,还有很多事情需要去做。一个人做好,一个团队做好,一个部门做好,一个公司做好,挑战各有不同,诚如古人言,修身,治家,齐国,平天下,境界不同,或许可以类比。2009年,挣扎彷徨在个人技术能力与团队之间,结果技术能力没有多大增长,团队管理也不尽如人意,这是硬伤,2010年,这两个方面需要平衡好,最大的挑战。

2010,我的wishlist,实际上主要三点昨天也在twitter上唠叨过了:

  • 技术上远离一线操作,更需要精研深入,Oracle和MySQL方面至少各看一到两本好书
  • 英语,年年念叨,年年没进步,2010,希望能达到初步口语沟通
  • 技术之外,看十本书,小说,历史,经管,皆可
  • 拿到驾照,2009年4月份就报考,却一直没有去练车,拖到2010,必须完成
  • 拿到房子,准备装修。房子交付在2010年底,估计也只能是先做准备
  • 写一本书,总结这两年Oracle的经验。如果2010年再不写,估计就再也写不出来了
  • 买一辆车,不需要太好,代步足矣
  • 至少出国旅游一次,已经定了4月去东南亚的行程,应该靠谱。

希望我的2010,搅他个风生水起。待明年今日,再细数往事前程。


常用标签: oracle life MySQL Oracle11g blog dba 新特性 oow2009 oow linux

最新评论 | Recent comments

  • guanghui: 我很早就开始关注zfs,然后自然也关...
  • thomas zhang: 这个bug是够恶心的 官方11.2.0.2 Release...
  • 巫师勋: 这里面有一些理念和ASM很像啊,确实...
  • 大头刚: EXT4 对内核的要求太高,大规模的迁...
  • ruochen: ext4的稳定性现在应该说已经很不错了...
  • Rain@DNA: 是的,目前的一些主流版本里已经集...
  • icavy: 这里探讨 404错...
  • 驾照: 哥们挺厉害的。我练了好久,倒桩和...
  • icavy: 现在不用穿墙也可以...
  • NinGoo: @supsyg 这个应该是tnsname本身有问题吧...
  • supsyg: 试了一下,速度还不错,但tns连接好...
  • 再现9527: 多开开就好,现在的驾校培养出来很...
  • 曾经的阿飞: sysbench可以使用oltp-table-size指定自动...
  • 曾经的阿飞: 你说concurrency参数是不是和sysbench的num...
  • ppg: 有车之人,羡慕啊,正努力赚钱中.....