ITPub博客

声明：下面的讨论的是开放平台的DB2（unix,linux,windows）,大机环境中的DB2又是另一个天地了，不讨论。如果从技术成就感的角度来说，选择DB2是很不错的。为什么？DB2的从业人数少，竞争压力也相对小，结果是在国内无论是IBMer还是甲方的DBA绝大多数水平不是很高（话虽难听但是事实），10+年的DB2 DBA废柴并不少见。新人有福了，学个一年半载就可以吹吹牛唬唬人了^_^这种“成就感”是很让人愉悦的但对于热衷于技术研究的DB2er来说随着时间的推移郁闷就逐渐开始了。你会发现绝大多数的职位其实只是要求“懂”即可，而且面试官的技术水平也不

前面的blog里我说过在DB2中随便拿一个自增量列“创造”主键是很垃圾的行为，“业务无关”的主键是垃圾主键。只有在考虑某些特殊的管理要求时才需要这么做。但我们都会看到在mysql的项目中这种行为是很普遍的，何故？其实用自增列创造主键在mysql中也是基于管理的考虑而并非是业务的选择。[@more@]严格来说只有在innodb引擎（SolidDB引擎用的较少）中这种设计才是可取的。基于innodb引擎表是索引组织表，并非一般数据库中常见的堆表（DB2中全是堆表）。表中所有数据都存储于cluster index中，cluster index默认按照primary key聚集，如果没

在实现online ddl上pt-online-schema-change 还不错不过默认pt-online-schema-change在主库更改后会全部复制到从库上，一旦有问题风险较大。对这类操作我们习惯是先在从库修改，然后再主库修改。我对这个工具做了个小的修改，增加了--skip-binlog 参数来避免工具的操作写入binlog。如果不加--skip-binlog参数则与工具之前行为相同，加入该参数只是工具的操作不写入binglog，不影响其他session，不用担心丢数据下载后覆盖原文件即可，版本：percona-toolkit-2.1.1免责声明：如果计划使用请先在测试环境进行测试pt-online-schema-change.rar

近两年greenplum比较火，在推出之初便被众多DBA和架构师所关注。Share nothing的架构、线性扩展的能力、处理大量数据的美好前景一时被津津乐道，仿佛发现了“新大陆”。看过比较多的文章后发现一个比较诡异的现象：DB2被大家选择性的“遗忘”了，其中不乏包括一些很有名的DBA或架构师[@more@]Share nothing的架构在DB2（LUW平台）中可谓是历史悠久了，到目前为止算起来都已经接近20年了。V5 V6 V7版本中叫EEE V8以后称为DPF。 greenplum的性能与DB2相比目前为止还是有相当大的差距的，尤其是稍微复杂点的逻辑，greenplum优化器的劣势就更明

在使用DB2的联邦功能时在创建nickname及使用nickname的时候最常见的报错就是SQL1101N，提示用户名或者密码不对不能访问远程数据源。下面说一下最常见的原因。 [@more@]一 创建过程中报错创建db2的联邦通常包含以下四步：1 CREATE WRAPPER DRDA2 CREATE SERVER 3 CREATE USER MAPPING4 CREATE NICKNAME 本地sample数据库要与远程qa数据库做联邦，qa数据库已经编目到本地，实例参数FEDERATED已开启，实际创建过程如下：db2inst1@lbdb:~> db2 connect to sampleDatabase Connection InformationDatabase server = DB2/LINUXX8664 9.7.4SQL

关于主键本来一直觉得这没什么好说的，很简单的内容，也没怎么太在意并强调。但最近在看了公司的数据库设计之后，发现问题还真不小。[@more@]在公司所有的数据库设计中，每个表都定义一个ID列作为主键 int类型，该列采用自增或者使用sequence。问其原因，答曰“主键要具有业务无关性”。同时baidu一把，乖乖不得了，网上铺天盖地的文章在强调主键一定要与业务无关。看看好几篇文章写的内容应该是工作了一定时间后才有的心得。我在给别人讲技术内容的时候总是喜欢先讲基础理论，然后讲应用。很多人不喜欢看基础理论，认为基础理论没什么用。

目的很简单就是要实现读写分离，目前用的是sql复制和Q复制。一直想实现从DB2复制到mysql，可目前商业的软件可选择的不多，我只知道GoldenGate可以，目前已经被Oracle收购了，收费挺高，而且license跟机器绑定，NND想盗版都不行。大规模使用价格不菲，背离了目标之一成本。最后打算自己写程序实现，可咱是运维出身，以前学的编程知识都忘的差不多了，每次申请个开发的兄弟，总是说人手紧张，暂时不行。有开会讨论的时间，活都能干完了。一硬头皮自己来。到今天差不多2个月，除去其他活，写程序有一个月多时间，还好今天测试比较顺利。第一期

相信用过mysql的db2er们都会对mysql的processlist功能印象深刻，反正我是这么感觉的。非常简单但很直观。跟db2，oracle等商业数据库比mysql提供可监控的指标及相应信息等非常少，但就是这么少的东西反而被理解的很深刻应用的很好。相比之下DB2提供了如此之多的可供参考的信息，但我们db2er们又理解了多少呢？这方面真应该跟mysql DBA们多学习一下。 [@more@]工具下载：sqllist_fu废话不多说了，本来初衷是在DB2上打算写一个与mysql的processlist相似的工具，但考虑到db2上的链接动辄几百乃至上千个，都显示不直观并且对问题诊断意义也不太

根据要求在IBM 小机上安装suse10，并且要联接DS4800。安装完系统后首先要安装RDAC，过程如下：1 下载操作系统相应版本的RDAC2 解压3 编译make cleanmakemake installls -l /boot确认生成了.img文件4 修改/etc/yaboot.conf(或者/etc/lilo.conf)修改initrdinitrd = /boot/mpp-`uname -r`.img //修改为刚生成的.img文件5 reboot[@more@]前三步一般不会出现什么问题,问题在第四步。在第三步install结束的时候提示修改/etc/lilo.conf，可无论我怎么修改重启都不加载mpp，郁闷。仔细的看了Readme并man lilo，man中有这么一段内容：lilo currentl

来源http://fuleqing.itpub.net/ 转载请注明作者和出处。 记得在09年系统架构师大会上一个51.com的DBA秀了一个mysql的小“魔术”，其大概过程是不更改数据库表中的数据，只是执行了一下flush table表中的数据就全部改变。之前没研究过mysql，一时也不明就里。这两天对mysql很感兴趣，想起了去年这位老兄的“魔术”。今天就做了个测试重现了一下这个场景。 [@more@]测试过程如下：mysql> select * from test;+------+| name |+------+| 1 | | 2 | | 3 | | 4 | | 5 | +------+5 rows in set (0.00 sec)mysql> select * from test;+---

在调整DB2 performance的时候经常看见不论是甲方还是乙方中的众多工程师有很大的误区，让人如鲠在喉不吐不快最多的问题：过于关注bufferpool，不理解在线交易系统和BI系统的区别，不能从整体上看问题。[@more@]现在基本上是个DB2的工程师就知道bufferpool很重要，包括IBM的很多人上来先问:你的机器内存多大？8G。那你应该至少把bufferpool设置为4G。曾经见过一位搞DB2 5，6年的老兄维护的一套交易系统，操作系统是linux，系统配置较低内存比较小8G，该老兄把bufferpool设置为了5G，系统跑的非常差。我看了看系统内存和swap分区频繁交换。存

DB2单机在更改为DPF后在redistribute数据的时候，db2会one by one的处理partition group中的表。在分发表中数据时会对表加“Z”锁，而且速度很慢。要是小表还可以，大表速度就不太能让人接受了。要是数据量大而且停机时间有限建议还是考虑创建新的DPF并装载数据。[@more@]

之前公司的几台机器没有加入HMC，为了方便管理把以前的小机添加到HMC.添加“受管系统”成功但在打开终端窗口时却不能进入系统。telnet至550，把tty设置为Enable LOGIN enbale后可以成功登陆[@more@]

公司新买的DS5100存储在测试阶段登陆存储偶然发现提示Logical Driver not on preferred path，好几个lun都挂在A控。刚开始没太在意还以为当时我划分的时候手动指定控制器时设置的不好。又手动把几个LUN切换回B控。但过了几天再看又发现有几个LUN切换回A控。这下明白了不是我手动设置的问题。[@more@]首先想到打800让IBM的人来看看，结果来的那位老兄貌似白痴状。告诉我这个问题很正常很常见不是什么大问题要么这么留着，要么再手动设回去。Shit！我跟这位老兄说设回去有什么用还会自己又切回来有什么用。让这位老兄走了以后我仔细想了一下

一天同事用图形工具尝试列出数据库的tablespace时报错SQL0970N 系统尝试写入只读文件。查看db2diag.log[@more@]2009-10-19-13.56.01.593616+480 E3060522565E589 LEVEL: WarningPID : 6879 TID : 46926678452544PROC : db2sysc 0INSTANCE: db2inst1 NODE : 000 DB : QALOGDBAPPHDL : 0-2070 APPID: *LOCAL.db2inst1.091019055732AUTHID : DB2INST1EDUID : 239 EDUNAME: db2agent (QALOGDB) 036535,49 36%[5] 0x00002AAC8255E848 sqloSystemErrorHandler + 0x6C0[6] 0x00002AAC81E6CD7A sqloqualifydir + 0x3B2[7] 0x00002AAC81E1911C /opt