《DB2设计与性能优化》作者做客ITPUB，举办DB2提问有奖活动，活动结束！

张广舟

原帖由 Ryan-liumin 于 2011-5-12 18:25 发表
DB2是不是适合任何数据库的需求？

不存在一种数据库适合任何数据库的需求。

张广舟

原帖由 〇〇 于 2011-5-11 20:28 发表
我有下面几个最近遇到的具体的问题，希望作者解答
1.分区内并行对查询的帮助大否
2.如果没有创建索引或主键，是否会导致很差的执行计划，比如下面的查询
select   
        s_acctbal,
        s_name,
        n_name,
        p_partkey,
        p_mfgr,
        s_address,
        s_phone,
        s_comment
from
        tpch.part,
        tpch.supplier,
        tpch.partsupp,
        tpch.nation,
        tpch.region
where
        p_partkey = ps_partkey
        and s_suppkey = ps_suppkey
        and p_size = 9
        and p_type like '%TIN'
        and s_nationkey = n_nationkey
        and n_regionkey = r_regionkey
        and r_name = 'MIDDLE EAST'
        and ps_supplycost = (
                select
                        min(ps_supplycost)
                from
                        tpch.partsupp,
                        tpch.supplier,
                        tpch.nation,
                        tpch.region
                where
                        p_partkey = ps_partkey
                        and s_suppkey = ps_suppkey
                        and s_nationkey = n_nationkey
                        and n_regionkey = r_regionkey
                        and r_name = 'MIDDLE EAST'
        )
ORDER BY s_acctbal desc,
        n_name,
        s_name,
        p_partkey ASC
fetch first 100 rows only;

1.分区内并行在CPU利用率比较低的情况下使用，能充分利用CPU资源，对性能有帮助。但要注意启用分区内并行会有一定的额外消耗。

2.索引和主键对性能和查询计划有非常大的影响。

对于这个查询，如果partsupp是大表，应该创建（ps_partkey，ps_suppkey）主键并建立索引（DB2会在主键上自动创建索引）。其他表上如果可以的话也应该主键和索引。这些主键和索引将使优化器得到较好的代价和中间结果估计，找出最优的连接方法、顺序。

tti76543

原帖由 张广舟 于 2011-5-11 16:41 发表



Hi， 你的第一个问题可以变成一块披萨饼引发的争议，在我看来，它和馅饼没太多区别。

第二个问题，如果你有一份这辈子不会换的job，那何必学两种数据库呢？ 不必太辛苦嘛。但如果并非如此，那就要考虑了，当前在金融、电信、中央部委、大型商用单位等需要大型数据库的环境中，这两套数据库并存是比比皆是的，客户们很少把鸡蛋放在一个篮子里，他们需要一个平衡的“安全”环境。那么对数据库工作者来说，你的视野如果更加广阔，你的知识库能兼容掉两种数据库，这样的话，会为你的履历在这个层次上增加更多的选项。 而要是从物以稀为贵的角度来讲，当前在中国懂db2的人手要比懂oracle的数量少，这意味着什么？我想你已经有答案了。

我再延伸一个问题，跟第一个问题又有关系了： DB2与Oracle距离很远吗？  无论是在班加罗尔，还是在硅谷，两家离得都不远。在北京的软件园里，DB2研发人员站在IBM的楼里，可以清楚的看到街对面Oracle研发人员坐在甲骨文的椅子上冲着这面笑，还有许多表情。。。

你会不会把我的表述联想到肯德基的对面一定有麦当劳？

  浅而易见的道理 ， tks

〇〇

原帖由 张广舟 于 2011-5-13 09:15 发表



1.分区内并行在CPU利用率比较低的情况下使用，能充分利用CPU资源，对性能有帮助。但要注意启用分区内并行会有一定的额外消耗。

2.索引和主键对性能和查询计划有非常大的影响。

对于这个查询，如果partsupp是大表，应该创建（ps_partkey，ps_suppkey）主键并建立索引（DB2会在主键上自动创建索引）。其他表上如果可以的话也应该主键和索引。这些主键和索引将使优化器得到较好的代价和中间结果估计，找出最优的连接方法、顺序。

已经都加过了，还是这样的结果

-- Sccsid:     @(#)dss.ri        2.1.8.1
-- TPCD Benchmark Version 8.0

--CONNECT TO TPCD;

--ALTER TABLE REGION DROP PRIMARY KEY;
--ALTER TABLE NATION DROP PRIMARY KEY;
--ALTER TABLE PART DROP PRIMARY KEY;
--ALTER TABLE SUPPLIER DROP PRIMARY KEY;
--ALTER TABLE PARTSUPP DROP PRIMARY KEY;
--ALTER TABLE ORDERS DROP PRIMARY KEY;
--ALTER TABLE LINEITEM DROP PRIMARY KEY;
--ALTER TABLE CUSTOMER DROP PRIMARY KEY;

  
-- For table REGION
ALTER TABLE REGION
ADD PRIMARY KEY (R_REGIONKEY);
  
-- For table NATION
ALTER TABLE NATION
ADD PRIMARY KEY (N_NATIONKEY);
  
ALTER TABLE NATION
ADD CONSTRAINT NATION_FK1 FOREIGN KEY (N_REGIONKEY) references REGION;

  

-- For table PART
ALTER TABLE PART
ADD PRIMARY KEY (P_PARTKEY);

  

-- For table SUPPLIER
ALTER TABLE SUPPLIER
ADD PRIMARY KEY (S_SUPPKEY);
  
ALTER TABLE SUPPLIER
ADD CONSTRAINT SUPPLIER_FK1 FOREIGN KEY  (S_NATIONKEY) references NATION;

  

-- For table PARTSUPP
ALTER TABLE PARTSUPP
ADD PRIMARY KEY (PS_PARTKEY,PS_SUPPKEY);

  

-- For table CUSTOMER
ALTER TABLE CUSTOMER
ADD PRIMARY KEY (C_CUSTKEY);
  
ALTER TABLE CUSTOMER
ADD CONSTRAINT CUSTOMER_FK1 FOREIGN KEY  (C_NATIONKEY) references NATION;

  

-- For table LINEITEM
ALTER TABLE LINEITEM
ADD PRIMARY KEY (L_ORDERKEY,L_LINENUMBER);


  
-- For table ORDERS
ALTER TABLE ORDERS
ADD PRIMARY KEY (O_ORDERKEY);

  

-- For table PARTSUPP
ALTER TABLE PARTSUPP
ADD CONSTRAINT PARTSUPP_FK1 FOREIGN KEY  (PS_SUPPKEY) references SUPPLIER;

  

ALTER TABLE PARTSUPP
ADD CONSTRAINT PARTSUPP_FK2 FOREIGN KEY (PS_PARTKEY) references PART;


  
-- For table ORDERS
ALTER TABLE ORDERS
ADD CONSTRAINT ORDERS_FK1 FOREIGN KEY  (O_CUSTKEY) references CUSTOMER;


  
-- For table LINEITEM
ALTER TABLE LINEITEM
ADD CONSTRAINT LINEITEM_FK1 FOREIGN KEY (L_ORDERKEY)  references ORDERS;

  

ALTER TABLE LINEITEM
ADD CONSTRAINT LINEITEM_FK2 FOREIGN KEY (L_PARTKEY,L_SUPPKEY) references
        PARTSUPP;

王飞鹏2011

您好！首先感谢您对我们的支持。关于Infomix暂且不评论，下面回答几个，供参考：

>>一、DPF有什么好的高可用方案
ISAS里面集成了HA的方案。不知道好的程度能不能达到客户的要求。也就是有一台备机，当DPF中的一台机器出现问题的时候，就在备机上takeover那个机器上的所有资源。
DB2有一个工具叫db2haicu，里面配置的时候有DPF的高可用性方案，有两种：N+1和N+M。但是cluster manager是使用DB2集成的TSA。目前我们中国的客户还没有采用过这个方案。

>>二、HADR会向INFORMIX的MACH11发展吗
不会，没看出来MACH11有什么优势。

在下一个版本里面，HADR的功能得到了很大改善，包括监控上的增强。其中两个最大的功能是开始支持多点灾备，支持DPF和purescale。加上这两点，我的感觉是HADR的功能要强于INFORMIX MACH11.

>>三、曾和某大型券商交流，从他们的证券集中交易系统HACMP+HADR使用经验看，最终只起到DR的作用，HA总是让人扼腕叹息。某人说NEAR-REAL-TIME-IN-SYNC是钱的问题，有多少钱就有多near。不清楚中国银联的高可用设计，感受不到钱多好办事^_^
这个问题客户是不是为了调侃你？据我的经验，我们的很多客户都对HADR的HA功能很认可，包括雀巢，百事等等。我没有听说过客户抱怨HACMP+HADR只能起到DR的作用。如果证券系统的使用感受真的这样的话，我想我们要必要拜访一下他们，好好听一下客户的痛苦点。如果确实是这种情况，我们可以想一些办法对产品进行改进；如果是因为客户的使用问题，我们也可以帮他们做一下部署上的调整。客户有没有告诉你证券商为什么这样抱怨？

最后，是关于federation server。在下一个版本（代号为：Galileo）里做了改进, 不用创建nickname也能访问远程表。使用方式为：<server_name>.<remote_schema>.<remote_tablename>
以后可能会做进一步，采用 “实例名@表名:机器名”的形式访问远程表。
另外federation server 支持drda数据源的两阶段提交。

fengfeng0821

有没有相应的工具可以直接将Oracle的数据迁移到DB2上？
应用从Oracle迁移到DB2上，能不能做到代码无需修改呢？

王飞鹏2011

IBM提供了一个工具叫IDMT，可以直接将Oracle的数据迁移到DB2上。在打开兼容模式后，只有5%不到的应用代码需要更改。
具体的情况，请参考我写的本系列第二本《从Oracle到DB2开发从容转身》。

bitiwyh

1.sql limits为什么限制得那么死?
  当一个表设计的行长超出限制后,就不能增加列了.但oracle,sqlserver等还可以继续添加,给出警告.只有在数据实际超出时才会出现错误.
  虽然,看上去,这样的表设计不怎样.但在一些泛应用的开发中还是会带来一些方便.
2.是否有一些适合开发者使用的一般调优工具,或者说了解性能瓶颈在的工具?
  在没有专业DBA的时候,开发者容易掌握的一些工具,方法和手段... 像oracle的topsql,执行计划等等.
3.重装系统后,怎么做才能不用重装?
  自己用的机子,时有重装.DB2相关套件都不在系统盘.但每次重装都需要重装才能,即使只是想要个client.google了好一阵也没能找到方法.
  是否有办法? ^_^

lwei_998

很想了解一下DB2的备份和恢复机制是什么样的？能否详细讲一下恢复机制。

陈辉2011

DPF                               MDC                                    Table Partition
DB2的分区有DPF，MDC和RP三种，各种分区的粒度不同。在本书的第三章有他们详细的介绍。下面是一个简单的比较，希望对你有所帮助。

中文名称        数据库分区特性                  多维聚类                                表分区
建表语句        DISTRIBUTE BY HASH        ORGANIZE BY DIMENSION        PARTITION BY RANGE

特性             将行均匀地分布在多个           将在多个维上具有近似值的行放在   将所有行放在同一个数据分区的一个指定范围的维中
                  数据库分区上                      表中相同的物理位置，即所谓的块
                                    
使用场景        大型表——大到无法仅依靠      结果集返回在多个维上具有近似值  这种类型的表：周期性地添加大量数据，然后在数据到期后又删除大量数据
                  单独一组 CPU 和 I/O 通道     的行的查询
                  来处理               
优点            可伸缩性——随着数据库的       查询性能——组织数据的方式有利   数据移动——通过添加和删除整个数据分区，可以增加和删除大量数据
                 增长增加计算资源                 于获得更快的检索速度，对于由多
                 （也就是数据库分区）            个谓词指定范围的查询尤其有效   

设计注意事项  1．对于大型 BI 应用程序，    1．MDC 可用来提高查询性能以及   1．RCTs）来进行对数据的快速直接的访问。
                  可以使用数据库分区以提高         转入和转出数据。                  2．基于转入和转出特点来设计表分区。根据 month 或财季来进行分区是很好的策略
                  其可扩展性。                     2．使用表分区来转出或在一个单独
                 2．在选择分区键时，同时            的维度通过使用 MDC 来转入
                 还要关注分区键值的高基数
                 并提高连接中的表并置。对
                 不共享数据库来说，使用
                 哈希分区完全是为了数据仓库

[ 本帖最后由 陈辉2011 于 2011-5-15 15:43 编辑 ]