ITPub博客

Top 10 Reasons to Consider DB2 10 for LUWBlog: DB2 News | By: Vijay Sitaram | Released: Apr 03, 2012 02:42 PMIt seems like yesterday when we took the wraps of DB2 V9.7 for LUW. I admit it is a kid in the candy store moment every time I get my hands on a newer version of DB2. The new features and enhancements in this new release address the needs of our business, directly improving availability, reliability and performance. This release also has enhancements that simplify security and reduce cost

广东移动经营分析系统的数据仓库情况介绍：03 底开始建设到现在，50 T -100T 的数据仓库，节点数 32 个ETL 入库每天 20亿条记录数据库系统容量 100 T ETL 系统为 20 T硬件状况 200 T 的阵列，IBM P595 系列主机 OLTP 交易，数据的增长（7000万用户，每天清单30亿）[@more@]

分表运作流程 就我所接触到的BI系统来说，系统中有几千的作业，每个作业对应着一个系统命令调用，各种shell,perl处理脚本，存储过程等，这些作业通过一个作业调度系统来维护，作业有两种触发方式一种时间触发，一种事件触发。对于库表维护的流程是：一.运作人员手工执行建表语句或脚本创建，删除。(比如日表，非周期性创建的表)二.通过定义一个建表的作业，让调度系统定时的或事件条件满足时触发。一般删表是批量手工维护。[@more@]

查看执行计划的两种方式：1.db2 -tvf $DB2HOME/sqllib/misc/EXPLAIN.DDLdb2 set current explain mode explaindb2 "statements"db2 set current explain mode nodb2exfmt -d bidw -u username password -w -l -s % -n % -o explain.outcat explain.out 2.db2expln -d bidw -u username password -g -t -q "statement";eg:db2expln -d bidw -u username password -g -t -q " statemens"===============================db2exfmt o Table Operatorsdb2exfmt TBSCAN - Table Scandb2exfmt IXSCAN - Index Scan

表连接的执行步骤，算法对称美：如果一个连接涉及两个以上的表，那么应从头到尾阅读说明步骤。例如，假定说明输出包含以下数据流： Access ..... W Join | Access ..... X Join | Access ..... Y Join | Access ..... Z执行步骤将是： 从表 W 中获取合格行。 将 W 中的某一行与表 X 中的下一行连接，并将结果命名为 P1（表示编号为 1 的部分连接结果）。 将 P1 与表 Y 中的下一行连接，以创建 P2。 将 P2 与表 Z 中的下一行连接，以创建一个完整的结果行。 如果 Z 中存在其他行，那么转至步骤 4。 如果

问题:特殊字符^M引起的数据导入问题:问题描述:在完成需求时需要通过系统门户网站上传原始数据,在到生产环境登录ftp下载数据.一次在从ftp下载下来数据,使用load导入数据库的过程后,发现导入的数据与文件中的数据不一致,字段被截取了.使用命令:cat -v source.txt 查看文件发现每行记录后有一个特殊字符^M(经查该字符可通过ctrl+v+m输入),使用命令:sed 's/^M//g' source.txt 替换掉^M字符,再次导入,成功.问题分析:关于使用ftp传输文件的两种方式:binary asciibinary:以二进制比特流传输文件,保留了原文件中的所有所以字符信息ascii:以ascii码

[Icefeish@#][19 /etl1_home/kft/Icefeish]$db2 "select count(*) from DM.TM_USSD_BASE_BUSI_DAY_GZ007 with ur "1 -----------SQL30080N A communication error "DRDA wrapper: 30081" occurred sending or receiving data from the remote database. SQLSTATE=08001===================相关解释SQL30080N将数据发送至远程数据库或从远程数据库接收数据时，发生通信错误 原因码。说明原因码 包含通信管理器报告的原始错误代码。对于 APPC 错误代码，格式是 pppp-ssssssss-dddddddd，其中 pppp 是主返回

联邦数据库配置步骤: db2 update dbm cfg using federated yes #参数配置db2 catalog node #编目节点db2 catalog database #编码远程数据库db2 connect to db #连接本地数据库db2 create wrapper drda #创建wrapperdb2 create server　　 #创建服务器db2 create user mapping　#创建用户mapping db2 create nickname　 #创建远程数据库对象nickname********************************************************************************* 1.设置数据库属性db2 update dbm cfg using federated yes db2stop db2

关于在DB2中模拟truncate操作,查看空间释放和HWM情况:1.load/import from /dev/null of del replace into wm.test_truncate_table nonrecoverable;2.delete from wm.test_truncate_table ;3.alter table wm.test_truncate_table activate not logged initially with empty table;--DB2数据库版本[431/app/etl/]db2levelDB21085I Instance "db2root" uses "64" bits and DB2 code release "SQL09018" with level identifier "02090107".Informational tokens are "DB2 v9.1.0.8", &quot

[Icefeish@#][24 /etl1_home/kft/Icefeish]$db2 "select count(*) from DM.TM_STU_INFO with ur "1-----------11702801 record(s) selected.[Icefeish@#][25 /etl1_home/kft/Icefeish]$db2 "select count(*) from ref.tr_nbrseg with ur "1-----------2712511 record(s) selected.CMD="update DM.TM_STU_INFO a SET BRND_CD=(select BRND_CD from ref.tr_nbrseg b where a.STUDENT_NBR between b.BEGIN_NBR and b.END_NBR fetch first 1 rows only )"EXEDB2_CMD--上面的语句导致CPU占用基本达到90%,此时执行

问题描述:在secureCRT上开了两个会话连接的数据仓库系统,A会话中执行一个大表的update操作,覆盖所有记录;B会话在此期间select该表当前记录数,发现记录数逐渐减少到零有增加到原记录条数.之前方向错了,想从update的处理机制来找原因,其实这个问题通过分析并发的隔离级别就可以很清晰了:DB2中列出的四种并发问题:? 丢失更新：这种情况发生在两个事务读取并尝试更新同一数据时，其中一个更新会丢失。例如：事务 1 和事务 2 读取同一行数据，并都根据所读取的数据计算出该行的新值。如果事务 1 用它的新值更新该行以后，事务 2 又更新了同一行

一例日志空间满带来的insert性能的优化：症状：大型数据仓库系统，至少有20个终端连接上去做查询等运维处理。手工调起一个脚本，该脚本中使用insert...select的方式将一个较大数据量的表的数据抽取部分字段到另一张表中,后系统反应变慢.--应用报错如下:Step 2: CMD=[insert into kf2.MM_test_cdr select 201008, 'AA', A.USR_MOB_NBR, A.B_NBR, A.LOCAL_CD, A.CELL_CD, A.B_BRND_CD, A.CALL_DT, A.CALL_CNT, A.CALL_DUR, A.DIR_TYP_CD from ods.to_cdr_AA201008 A with ur] DB21034E The command was processed as an SQL statement becau