当前访客身份:游客 [ 登录 | 加入开源中国 ]
当前访客身份: 游客 [ 登录 | 加入开源中国 ]
晨曦之光 晨曦之光
勤能补拙
博客分类
最新评论
访客统计
  • 72
  • 207
  • 279
  • 279
  • 444728
  • 092012-03

    下表显示的是这些角色彼此之间如何进行交互,这些角色执行时需要哪些技能,以及这些执行专业人员可以使用哪些工具: 

     

    项目角色 执行的任务 协助人员 必备技能 支持工具
    SOA 架构师 解决方案轮廓
    需求分析
    体系结构决策
    组件建模
    操作建模
    所有其他的组员 一般 IT 体系结构
    J2EE 技术
    XML、XML Schema
    Web 服务概念与平台、最佳实践
    UML 编辑器、office 系列工具
    服务建模人员 接口契约设计
    WSDL 编辑(自顶向下、自底向上、中间相遇)
    商业分析员
    SOA 架构师
    服务开发人员
    WSDL
    XML Schema 和名称空间
    J2EE 技术
    WSDL 编辑器、Java 到 WSDL 生成器
    流程流设计人员 业务流程建模
    将原子服务组装成链(流程)
    服务建模人员
    商业分析员
    SOA 架构师
    BPEL4WS、WSDL 图形流建模工具、BPEL4WS 生成器
    相应的运行时间支持
    服务开发人员 服务提供者编码
    服务请求者编码
    提供 SOAP 头处理程序(如果需要的话)
    代码文档化
    SOA 架构师
    服务建模人员
    互操作性测试人员
    J2EE、XML、SOAP、WSDL IDE 中的 Web 服务向导
    WSDL 到 Java 的生成器
    互操作性测试人员 WSDL 检查
    SOAP 信封追踪
    一致性测试
    故障诊断
    服务开发人员(请求者端和提供者端) SOAP、WSDL、WSI Basic Profile Version 1.0 TCP/IP 通道和监视器
    WSI 测试工具
    UDDI 管理员 UDDI 建模
    UDDI 植入
    UDDI 管理
    SOA 架构师、服务建模人员 UDDI 数据模型和 API知识数据库设计与管理 UDDI 浏览器
    UDDI4J

            

            识别角色是有帮助的,但是最关键的是找到具备适当技能的合适人员。不要低估这项工作的重要性。从技术上讲,Web 服务通常是轻量级且相当简单的;这是它们强大的一个方面。采用 Web 服务,孤立的异类系统之间的协作就必以前容易得多。然而,随着这些新的机会的出现,也会带来一些以往没有出现过的错误。Web 服务项目对于您的组织来说或许是一种 新的项目,但是很有可能它们将不是一种 更简单的项目。建议您召集具备在不同平台上工作的经验的专业人员。这对于您的 SOA 架构师来说尤为重要。如果您的组内没有这样的人选,您可以找一些辅助(业余)的副架构师来填补这个空缺,这样做也是可行的。

     

    人员到角色的分派

            每个角色都负责整个项目的一个不同方面。前面我们说过,一个人通常可以戴几顶帽子,换句话说,担当多个角色。如果各种具备渊博知识和多方面技能的人在一起工作,就会减少项目的风险。在有些情况下,只有这样的各种人开展有目的的合作才会揭示项目至关紧要的问题并且提出合理的解决方案。在另一方面,通信开销会随着每个新组员的加入而增加。没有单一且简单的答案来解决角色到人员映射的难题。关于应该如何着手处理这个问题存在许多不同的意见和争论(甚至本文的两位作者也没有达成一致的意见!)。

            我们不继续这些争论,现在让我们来看一个小例子。考虑下面的场景:我们虚构一家来自保险业的公司,这家公司决定构建一组新的 mid-office 业务应用程序来用于风险和策略管理,这不可避免地涉及两种不同的后端系统。两种后端系统都已经作为 J2EE 应用程序构建好了 —— 一个使用 EJB ,另一个只使用 Servlet、JSP 和 JDBC 来连接到它的客户和契约数据库。

            在已启动的开发项目的初始阶段,会将上面定义的角色分派到组员。除了 Web 服务的特定活动之外,还要确定和分派标准的项目任务和角色。下表列出的是这项工作分解训练的结果:

    组员 分派的角色 协助人员 实际任务 所选择的工具
    1 项目管理员 (所有组员) 项目规划
    正在进行的项目的管理
    电子表格、项目管理软件
    2 商业分析员 3 问题领域分析 流程建模工具、office 系列
    3 SOA 架构师
    服务建模人员
    Web 服务的知识转移服务商
    (所有组员) 软件和系统体系结构
    用于服务调用的 WSDL 模型
    Rational XDE、WebSphere Studio Application Developer
    从其他项目中获取的经验。
    4a 服务开发人员
    (单元)测试人员
    3、5、6 风险和策略管理服务请求者(客户端)的开发 WebSphere Studio Application Developer
    4b 服务开发人员
    (单元)测试人员
    3、5、6 两种服务提供者实现(EJB、非 EJB)的开发 WebSphere Studio Application Developer
    5 测试人员
    互操作性测试人员
    3、6 集成并连接由 4a 与 4b 开发的组件 JUnit、WSI 一致性测试工具
    TCP/IP 通道监视器
    6 服务部署人员
    系统管理员
    数据库管理员
    UDDI 管理员
    3、4、5 负责整个运行时体系结构 J2EE 部署工具、Ant
    产品的特定管理 GUI

            除了项目管理员和商业分析员以外,所有其他的组员都戴了多顶帽子。而且根本没有分派属于额外角色的流程流建模人员,因为在这个场景中它是不需要的。 同时需要注意的是,这个例子是相当简单的;在实际项目中,需要有更大的项目组。根据我们成功的经验,在核心组的大小最好为 7 到 10 个的范围内。这完全取决于您所处的场景;为了避免您的工作分解结构由于过于复杂而变得难以处理,您可以将项目分解成几个阶段。换句话说,要确保项目按计划循序渐进地进行。这可以让项目组成员有机会学习这项工作并减少项目风险。


    原文链接:http://blog.csdn.net/jaminwm/article/details/3429993
    发布于 2年前, 阅读(38) | 评论(0) | 投票(0) | 收藏(0) 阅读全文...
  • 092012-03

     set devmgr_show_nonpresent_devices=1
    cd /d

    %SystemRoot%/System32
    start devmgmt.msc

     

    在设备管理器中可以选择显示隐藏设备删除即可


    原文链接:http://blog.csdn.net/jaminwm/article/details/3465210
    发布于 2年前, 阅读(15) | 评论(0) | 投票(0) | 收藏(0) 阅读全文...
  • 092012-03

    一、如何提高NetView的性能?
    当网络规模比较大或有比较多的NetView客户端时,NetView会出现性能问题。以下为提高NetView的性能的几点建议:

    1、NetView Windows客户端的内存不小于192 MB;

    2、NetView Windows客户端的CPU速度不低于700 MHz;

    3、在做网络发现时,不要启动NetView客户端;

    4、当网络规模比较大,并且NetView客户端数目大于20时,把NetView服务器jetty.sh中的JVM mx数值设为128m;

    5、把ovwdb缓存设为端口(interfaces)数的2.5倍;

    6、监控 /usr 空间的使用情况;

    7、安装 NetView 7.1 Performance Patch。 

     

    二、安装CiscoWorks后,Netview有何不同?
    安装CiscoWorks的CWSI部分后,Netview会有以下变化:

    1、 Cisco设备的MIB文件被拷贝到Netview的相关目录下;
    2、Cisco设备会以Cisco设备的图标在Netview上显示;
    3、在Netview中选中Cisco设备即可启动CiscoView (Netview菜单,Monitor ->CiscoView)。
     
    三、怎样计算Tivoli Netview的授权许可
    Tivoli Netview在计算授权许可的时候,必须考虑两方面的因素,

    1、安装Netview Server的服务器,用户需要购买针对该服务器,购买足够数量的CPU授权许可(Processor)。

    2、Netview所管理的节点(Node),用户需要针对网络中的每一台设备,包括交换机、路游器、服务器、PC机等购买足够数量的节点授权许可(Node)。

     
    四、如何解决Netview(AIX)颜色显示不正常的问题?
    Netview(AIX)颜色显示不正常通常是因为安装了其它软件,如 Netscape 或 CiscoWorks,而改变了操作系统的调色板。这时需要调整操作系统的调色板来解决。


    五、如何维护Netview Database

        Netview共有三个数据库:
    1、Map Database
    2、Object Database
    3、Topology Database

    如果一个设备被Netview发现并管理,该设备一定存在于上面三个数据库中。如果某一个数据库中缺少了该设备,Netview将不能正常的工作。

    可以利用下面的工具来查看三个数据库的内容:
    1、Map Database -- ovmapdump
    2、Object Database -- ovobjprint
    3、Topology Database -- ovtopodump

    在对三个数据库进行操作之前,最好能够对数据库进行备份。它们分别是/usr/ov/databases/openview下面的mapdb, ovwdb和topo三个目录。

    1、如果在Map Database里面有该设备,但是Object Database和Topology Database中没有该设备。可以在Netview的Map上找到并删除该设备,然后重新发现。

    2、如果该设备存在于Object database,但是Map database里面没有该设备,可以利用'ovwdbdmap -d objectid'从Object Database中删除该设备。

    3、如果该设备只存在于Topology Database,而Map database,Object Database中没有该设备,可以利用'ovtopofix -r objectid'从Topology Database中删除该设备。
     


    原文链接:http://blog.csdn.net/jaminwm/article/details/3467424
    发布于 2年前, 阅读(44) | 评论(0) | 投票(0) | 收藏(0) 阅读全文...
  • 092012-03

    用于 Mac 的远程桌面连接客户程序仅支持端口 3389,这是默认端口

     

    可以使用 Windows XP Professional 中的远程桌面功能从另一台远程计算机连接到您的计算机。 警告:如果更改侦听端口,Windows XP 中的远程协助功能可能无法正常工作。 更改远程桌面的侦听端口:

    1. 启动注册表编辑器 (Regedt32.exe)。
    2. 在注册表中找到下面的项:
      HKEY_LOCAL_MACHINE/System/CurrentControlSet/Control/TerminalServer/WinStations/RDP-Tcp/PortNumber
    3. 编辑菜单上,单击修改,单击十进制,键入新的端口号,然后单击确定
    4. 退出注册表编辑器。

     


    原文链接:http://blog.csdn.net/jaminwm/article/details/4035673
    发布于 2年前, 阅读(105) | 评论(0) | 投票(0) | 收藏(0) 阅读全文...
  • 092012-03

          客户之所以选择 IBM DB2 数据库,是因为它能够在难于置信的时间内实现其价值,能够跨各种不同的环境伸缩和集成,还有其健壮性以及极少的停机时间(包括计划内的停机和计划外的停 机)。我听到了很多关于高可用性(high availability,HA)环境中 DB2 的许可方面的问题,高可用性环境的设计目标是减少计划外停机(有时候也包括计划内的停机)。通常,人们的第一层困惑的原因是:在为高可用性环境中的数据库 产品定价时,不同的供应商总是花样百出。

    另一层困惑主要集中在讨论高可用性时所使用的术语方面。例如术语集群(cluster)。 有时候 IT 行业将高可用性环境称作集群。而我不喜欢使用这个术语,因为该术语用到后来已经有点儿被滥用的感觉,集群可以指以提高可伸缩性为目标的集群(例如 DB2 数据库分区特性 - DPF),也可以指以提高可用性为目标的集群(例如,在一组 Windows 服务器上使用 Microsoft Cluster Server)。尽管我不喜欢这个术语,但还是用了它;因此,在本文中,当提到术语集群 时,我指的是以提高可用性为目标的集群(另行注明的除外)。为简单起见,在与客户或同事讨论集群时,我建议在术语 “集群” 前面加上高可用性可伸缩性

    另一个容易产生困惑的地方源自在讨论出现停机事件情况时,用来描述用作故障转移服务器的服务器的术语。例如,这种服务器可能被称为备用(standby)从(secondary) 服务器(还有其他名称)。如果您接触这一方面的时间比较长,那么很可能对描述这种服务器的功能的术语已经很熟悉了。这些术语包括:idleactivecoldwarmhotpassive

    大多数情况下,IBM Software Group(IBM SWG)文献使用 coldwarmhot 这几个术语来描述备用服务器。在 DB2 9.5 之前,在 DB2 领域情况有所不同。DB2 8 和 DB2 9 使用术语 idleactive 来描述备用数据服务器。因此,DB2 8 和 DB2 9 中采用的定价和许可术语可能与其他 IBM SWG 术语不同,这也是常常令客户对高可用性许可产生困惑的源头。

     

    好 消息是,在 DB2 9.5 中,与高可用性定价相关的许可术语已经与 IBM SWG 术语一致了。例如,如果在高可用性集群中将一个 DB2 9 数据服务器配置为 sat idle,就必须为这个服务器授予部分许可。在 DB2 9.5 中,不再需要这样做了。如果在 DB2 9 中未启动的服务器上安装 DB2,那么也必须为这个服务器授予部分许可。在 DB2 9.5 中,不需要为未启动的数据服务器购买许可。

     

      简单地说,对于高可用性环境中 DB2 服务器的许可取决于您对以下这些关键问题的回答:

    • 您安装了什么版本的 DB2 数据服务器?

      它 是 DB2 Express-C、DB2 Express-C FTL、DB2 Express、DB2 Workgroup 还是 DB2 Enterprise?例如,DB2 Express-C FTL 对于备用服务器没有 hot、warm 或 cold 的概念(稍后进一步解释)。另外,不允许用 DB2 Express-C 建立高可用性集群。

    • 您要如何为 DB2 数据服务器颁发许可以确保高可用性?

      对于主流的 DB2 9.5 数据服务器(DB2 Express、DB2 Workgroup 和 DB2 Enterprise)有以下选择:授权用户许可(顾名思义,这种许可要识别每个最终用户)和称为 价值单元(Value Unit,VU) 的基于 IBM SWG 处理器的指标(这样就不需要计算用户数量)。如果使用 DB2 Express-C FTL,就要为每个物理服务器颁发许可。(关于所有分布式 DB2 9 数据服务器的概述以及许可方式,请参见 “Which distributed edition of DB2 9.5 is right for you?”。)

    • 没有出现故障 时,如何使用备用机器?

      是将它用作处理 DB2 事务和查询工作的生产服务器吗?这个服务器上的 DB2 实例启动了吗?这个实例可能正在执行某种形式的工作,而只是在出现故障事件时帮助启动恢复(例如在 HADR 场景中)。简单地说,当一切 正常时备用服务器正在做什么与如何为那个服务器上的 DB2 获得许可有很大的关系

    在讨论高可用性集群对 DB2 9.5 许可的影响时,首先给出与新术语相关的示例。DB2 9.5 定义了三种备用服务器: hot warm cold

    hot 备用

    hot 备用 配置中,所有服务器都有用于处理用户事务和查询的独立运行的 DB2 数据库。这种配置有时候被称作 active/active 配置,因为集群中的所有机器在所有时候都在执行某种级别的业务生产工作。如果高可用性集群中的某一个服务器出现故障,那么集群软件将把出故障的服务器上的工作负载转移到集群中仍然正常的一个服务器上。

    如果出现了故障,那么负载的转移将使 hot 备用服务器(两节点集群中仍然正常运行的机器)的工作负载加倍,因为现在这个机器必须处理它原先的工作负载再加上出 故障的服务器的工作负载。在设置任何高可用性环境时,都需要考虑这一点,在这种环境中,每个服务器互为备用,但是它们必须维持自己的服务水平。如果您是一 名数据库管理员(DBA),并且要满足一个苛刻的服务水平协议(SLA),那么这未必是最好的选择(除非调整其规模或使用 Xkoto GRIDSCALE 等技术限制其影响)。

    总 而言之,在 DB2 中,hot 备用服务器是在正常运行期间用来处理用户事务和查询的机器。当集群中另一个服务器出现故障时,hot 备用服务器将接管出故障的服务器机器上的负载,同时还要处理在正常运行期间它自己所执行的工作。因为即使没有故障出现,hot 备用机器仍用于处理用户事务和查询,所以它必须是获得完全许可的。例如,假设有两个数据库分别安装在两个不同的机器上,其中一个机器上运行 着一个企业资源计划(ERP)应用程序,另一个机器运行供应链管理(SCM)应用程序。如果 SCM 数据库出现故障,那么承担着 ERP 工作负载的机器将不得不同时为所有的 SCM 用户提供服务。有两个服务器,在正常运行期间,它们都用来处理事务和查询工作负载(实心框表示在出现故障之前每个机器的工作负载,交叉线 框是当两个机器分别出现故障时,工作负载所出现的地方)。在这个场景中,当机器 2 出现故障时,它的工作负载被转送到它的故障转移伙伴(即机器 1)那里。机器 1 是机器 2 的 hot 备用服务器(当您仔细观察这个图时,会发现反过来也是一样的 —— 注意机器 2 上原属于机器 1 的交叉线框)。这种类型的配置常常被称作高可用性集群对(high-availability clustering pair)孪生故障转移对(twin failover pair)active/active 对, 这在当今的 IT 环境中非常常见。有许多种在 DB2 中实现 active/active 高可用性集群的方法,根据解决方案的需求,可以使用数据库分区特性,在互为故障转移的每个服务器上的数据库中结合使用 HADR,使用 active 备用服务器通过快照技术或磁盘映像拷贝执行报告功能,使用 xKoto GRIDSCALE 技术。机器 1 和机器 2 一直用于处理自己的事务和查询工作负载,当机器 2 出现故障时,机器 2 上的 DB2 工作负载被转移到机器 1。在这种情况下,如果没有考虑到承担机器 2 的工作负载而对机器 1 的资源进行适当的调整(反之亦然),那么在出现停机并导致工作负载的转移之后,就会引起性能问题。

     

     

    对于 hot 备用机器在许可方面的考虑事项

    作为一般经验法则,active/active 配置的许可方式应该与各服务器没有参与高可用性集群情况下的许可方式相同。接下来的小节将详细介绍对于 DB2 数据服务器许可方式,您应该知道的一些考虑事项。

    价值单元(VU)许可:

    对于任何按照 VU 模型 颁发许可的 DB2 数据服务器,hot 备用服务器(这个例子中是机器 1)上的所有 VU 都必须得到许可(除非使用 DB2 Enterprise 中的子容量许可功能)。这种许可方式与服务器没有参与 HA 集群时一样,因为服务器用来处理生产负载,所以这没什么奇怪的。

    在图 3 所示的例子中,假设每台机器都运行 DB2 Workgroup(这个版本将服务器的最大 VU 级别限制为 400),那么必须购买共 800 VU 的许可:机器 1 的 400 VU 和机器 2 的 400 VU。

    授权用户许可:

    对于任何按照授权用户模型 颁发许可的 DB2 服务器产品,必须按照将访问它的授权用户的总数购买许可,这也包含将访问 active 主数据服务器的用户数(因为主数据服务器有自己的应用程序,而且它们互为备用服务器)。授权用户是一个个人(在某些情况下,如果它不代表其他用户,那么可 以是一个应用程序或设备),他具有在公司内外有效的身份。也可以通过因特网使用这些许可(比如在线银行应用程序),因为最终用户是已知的,因而必须被许可 明确识别。授权用户许可拥有完全的权力;不需要像 DB2 8 中那样另外使用服务器许可(在 DB2 8 中,用户权力必须与基本服务器许可结合使用)。如果使用多路复用或连接集中软件,那么需要首先完全识别这些用户,然后才能将这些技术应用于连接。

    对 于访问数据服务器的每个用户,都需要获得授权用户许可。但是,无论有多少用户访问数据服务器,至少要购买最低数量的授权用户许可:DB2 Express 和 DB2 Workgroup 数据服务器要求最少 5 个授权用户许可,DB2 Enterprise 数据服务器要求为服务器上的每 100 VU 至少购买 25 个授权用户许可。授权用户许可不能随工作转移而转移(但是可以由于雇用关系转移而转移),它们只对特定的 数据服务器有效。当然,因为这个示例是 active/active 配置,它们的许可方式与完全独立的 active 服务器相同,所以这些规则的意义不大。如果有 100 个用户需要访问两个 active DB2 Workgroup 数据服务器,那么需要购买 200 个 DB2 Workgroup 授权用户许可:2 个服务器 x 每个服务器 100 个授权用户。即使这些用户中只有 12 个用户同时连接这两个服务器之一,也必须为每个 数据服务器颁发所有 100 个用户的许可(所以这个示例需要 200 个授权用户许可)。使用 DB2 Express 或 DB2 Workgroup,而且公司中只有 3 个用户,那么需要 10 个 DB2 Express 或 DB2 Workgroup 授权用户许可(2 个服务器 x 最低授权用户数 5 个),这样才能满足这些 DB2 版本对最低授权用户数的要求。使用的数据服务器是 DB2 Enterprise,情况就不一样了。仍然以前一段中的情况为例,如果有 100 个用户需要访问两个 active DB2 Enterprise 数据服务器,那么需要购买 200 个 DB2 Enterprise 授权用户许可:2 个服务器 x 每个服务器 100 个授权用户。同样,即使这些用户中只有 12 个用户同时连接这两个服务器之一,也必须为每个 数据服务器颁发所有 100 个用户的许可(所以这个示例仍然需要 200 个 DB2 Enterprise 授权用户许可)。 DB2 Enterprise 数据服务器是 2 插槽基于 Intel x86 的双核服务器,那么这些服务器的总 VU 级别都是 200。如果公司中只有 3 个用户,那么需要 100 个授权用户许可(2 个服务器 x 200/100 VU x 25 个授权用户),这样才能满足这个 DB2 版本对最低授权用户数的要求。但是,如果 图 3 中的服务器是 2 插槽基于 Power5+ 的双核服务器,那么这些服务器的总 VU 级别就是 400。所以,对于这种服务器硬件,如果公司中只有 3 个用户,那么需要 200 个授权用户许可(2 个服务器 x 400/100 VU x 25 个授权用户),这样才能满足这个 DB2 版本对最低授权用户数的要求。

    正如前面提到的,DB2 Express-C 不支持 高可用性配置。但是,DB2 Express-C FTL 支持。在高可用性环境中为 DB2 Express-C FTL 颁发许可时,不采用本节描述的规则。因为 DB2 Express-C 是一种免费的数据服务器,而 Fixed Term License(FTL)是可以另外购买的支持和特性合约,所以采用另一种许可方式。在高可用性环境中为 DB2 Express-C FTL 颁发许可时,只需为集群中的每个服务器 购买支持合约,而不管采用哪种备用类型(hot、warm 或 cold);不需要识别服务器的活跃程度、最低用户数、底层数据服务器的价值单元级别和其他情况:非常简单!

     



    warm 备用

    warm 备用 配置中,在正常运行期间,高可用性集群中至少有一个服务器上没有 为用户事务或查询工作负载提供服务的 DB2 数据库。由于这个数据服务器没有执行 “有用的” 工作,因而说它是闲置的。被归为 “无用的” 工作(具有讽刺意味的是,这些工作实际上可能是服务器所做的最有用的工作)包括在故障转移场景中起辅助作用的一些管理工作,比如使处于前滚暂挂状态的数据 库支持日志传送(log shipping)、为 HADR 环境提供事务级日志传送支持等等。如果高可用性集群中某一个服务器出现故障,那么集群软件就会将工作负载转移到 warm 备用数据服务器。

     

    对 warm 备用配置普遍存在的一个误解是,warm 备用机器若专用于恢复操作,那就是对资源的浪费。如此理解这种配置是不对的。实际上,warm 备用机器不仅可以担任备用角色,还可以有很多其他用途(包括与 DB2 相关和不相关的用途)。例如,可以在 warm 备用机器上创建另一个 DB2 实例(根据要在那里执行的和 DB2 相关的工作,其中可能牵涉到许可问题),并使用它作为测试机器,还可以将其他工作负载和功能分摊到它上面来执行。当有故障发生时,可以推掉这些工作负载, 让 warm 备用机器使用全部资源来处理出故障的服务器的负载,这样便巧妙地解决了前面讨论 hot 备用配置时提到的负载问题。例如,可以让 warm 备用机器根据 DB2 日志进行前滚,与此同时,这台机器还可以在另一个实例中运行测试场景(或者与 DB2 无关的测试场景,例如应用程序测试等等)。当有故障发生时,只需暂停测试工作负载,让 DB2 承担出故障的服务器的负载,这样就不必担心吞吐量降低。给出一个 warm 备用场景。在这个示例中,当正常运行时,机器 2 用于处理事务和查询工作负载(在图中标为活动工作),而机器 1 作为机器 2 工作负载的 warm 备用,也可能支持某些额外功能,比如应用程序开发。一旦机器 2 出现故障,它的 DB2 工作负载被传递到它的 warm 伙伴机器 1。在这个场景中,情况很可能是这样的:如果在出故障之前(任何类型的)所有工作在机器 1 上执行,那么当机器 2 出现故障之后,这些工作就会收回,以便处理新的工作负载(或者,机器 1 最初确定的规模是同时支持它的工作负载和机器 2 的 DB2 工作负载,否则将出现性能问题)。由于从 DB2 的角度看来,在正常运行期间只有一台机器是活动的,而另一台在做其他事(比如准备 HADR 故障转移伙伴),所以这种配置常常称作 active/idle 配置。这里要注意的重要概念是,在发生停机之前,机器 1 不做任何 “有意义” 的 DB2 工作。根据您的可用性需求、工作负载等等,warm 备用可能适合您的环境,也可能不适合;然而,首先不要忘了高可用性环境的目标 —— 减少停机之后的平均恢复(MTTR)时间。

    warm 备用机器许可方面的考虑事项

    价值单元(VU)许可:

    对于任何按照 VU 模型 颁发许可的 DB2 数据服务器,无论 服务器基于哪种处理核心体系结构,都按照 100 VU 为 warm 备用服务器颁发许可。换句话说,尽管具有 4 个双核 AMD 处理器的服务器的 VU 级别是 400,而具有 4 个双核 Power5+ 处理器的服务器的 VU 级别是 800,但是在用作 warm 备用服务器时,只需按照 100 VU 为 DB2 软件颁发许可。假设每台机器都运行 DB2 Workgroup(这个版本将服务器的最大 VU 级别限制为 400),那么必须按照 500 VU 购买许可:warm 备用服务器(机器 1)的 100 VU 和机器 2 的 400 VU。

    授权用户许可:

    对 于任何按照授权用户模型颁发许可的 DB2 服务器产品,只需为 warm 备用服务器购买最低数量的授权用户许可。对于 DB2 Express 和 DB2 Workgroup,因为必须为物理服务器购买的最低授权用户许可数量是 5 个,所以 warm 备用服务器需要 5 个授权用户许可。在上面的示例中,如果一个 DB2 Workgroup 服务器是 hot 服务器并参与 active/idle 集群,而且您有 100 个用户,那么需要 105 个 DB2 Workgroup 授权用户许可:100 个授权用户 + warm 备用服务器所需的 5 个授权用户(当然,如果用户数低于最低值,那么 hot 服务器必须满足对授权用户许可的最低数量要求。)

    对 于 DB2 Enterprise,必须为 warm 备用服务器购买 25 个授权用户许可,这是因为在 VU 模型中一个 DB2 Enterprise warm 备用服务器按照 100 VU 颁发许可,而 DB2 Enterprise 要求每 100 VU 至少购买 25 个授权用户许可。如果有 100 个用户需要访问高可用性集群中的 hot DB2 Enterprise 数据服务器,那么需要 125 个 DB2 Enterprise 授权用户许可:100 个授权用户 + warm 备用服务器所需的 25 个授权用户。服务器是 2 插槽基于 Intel x86 的双核服务器,那么 hot 服务器的总 VU 级别是 200。如果只有 3 个用户访问 hot DB2 Enterprise 数据服务器,那么仍然需要 75 个授权用户许可:(hot 服务器的 200/100 x 25 个授权用户) + DB2 Enterprise warm 备用服务器的 25 个授权用户。但是,如果 服务器是 2 插槽基于 Power5+ 的双核服务器,那么 hot 服务器的总 VU 级别就是 400。如果只有 3 个用户访问 hot DB2 Enterprise 数据服务器,那么仍然需要 125 个授权用户许可:(hot 服务器的 400/100 x 25 个授权用户) + DB2 Enterprise warm 备用服务器的 25 个授权用户。

    正如前面提到的,DB2 Express-C 不支持 高可用性配置。但是,DB2 Express-C FTL 支持。在高可用性环境中为 DB2 Express-C FTL 颁发许可时,不采用本节描述的规则。因为 DB2 Express-C 是一种免费的数据服务器,而 Fixed Term License(FTL)是可以另外购买的支持和特性合约,所以采用另一种许可方式。在高可用性环境中为 DB2 Express-C FTL 颁发许可时,只需为集群中的每个服务器 购买支持合约,而不管采用哪种备用类型(hot、warm 或 cold);不需要识别服务器的活跃程度、最低用户数、底层数据服务器的价值单元级别和其他情况:非常简单!

     

    cold 备用

    cold 备用 配置中,在正常运行期间,集群中至少有一个服务器上没有 为用户事务或查询工作负载提供服务的 DB2 数据库。这个服务器也不执行在故障转移场景中起辅助作用的任何管理工作,比如使处于前滚暂挂状态的数据库支持 HADR;实际上它甚至可能不开机。给出一个 cold 备用场景。在 这个示例中,当正常运行时,机器 2 用于处理事务和查询工作负载(在图中标为活动工作),而机器 1 上没有启动 DB2 实例。一旦机器 2 出现故障,机器 1 就会启动并通过备份映像将 DB2 数据库恢复到某一时间点,然后继续处理用户事务。还可以将机器 1 配置在 TSA 高可用性集群中,但是不启动数据库实例。您可以看出,cold 备用配置并不是很好的可用性解决方案,因为它的 MTTR 通常比 hot 或 warm 备用配置长得多。

    但是,在某些环境中 cold 备用服务器是合适的。通常,我建议客户对应用程序的可用性需求进行多级的分类;例如,建立 Copper、Silver 和 Gold 级别。Copper 级别的应用程序可以采用 cold 备用,Silver 级别的应用程序采用 hot 配置,而 Gold 级别的应用程序采用 warm 备用。按照我的观点,如果需要最高的可用性,就使用 warm 配置并结合使用 HADR。通过使用专用服务器,可能(但也不一定)获得比 hot 备用配置更好的故障间平均时间(MTBF)和 MTTR(除非适当地确定其规模)。

    cold 备用机器许可方面的考虑事项

    从 DB2 9.5 开始,不需要为 cold 备用服务器颁发许可,因此没有许可方面的考虑事项。判断备用机器是否可以归类为 cold 备用的一条经验规则是,查看是否启动 DB2 实例;但是,这条规则有一些例外。例如,如果从生产服务器取得了快照映像,并且只为了执行备份而启动 DB2 备用数据服务器,执行备份之后就停机,那么也可以认为它是 cold 备用服务器,不需要许可。

    所以,采用 DB2 9.5 中新的高可用性许可规则可以帮助您节省资金。假设您要为使用 Database Partitioning Feature 的 DB2 9 环境颁发许可。这个集群由 5 个服务器组成,其中 4 个 hot 服务器的 VU 级别都是 800,它们都配置为向一个备用服务器(也是 800 VU)执行故障转移。在 DB2 9 中,因为没有 cold 备用服务器的概念,所以必须按照 Database Partitioning Feature 的 100 VU 和 DB2 Enterprise 的 100 VU 为备用服务器颁发许可。但是在 DB2 9.5 中,如果备用服务器上没有启动 DB2 实例,它就是 cold 备用服务器,就不需要支付许可费用。

    与 HADR 相关的高可用性定价

    当在高可用性配置中使用 HADR 时,备用服务器必须 按照 warm 或 hot 服务器颁发许可(取决于是否设置了孪生 HADR 故障转移场景)。

    从 DB2 9.5 开始,HADR 被包含在 DB2 Workgroup 中(它一直是 DB2 Enterprise 的组成部分)。在 DB2 9 中,在 DB2 Workgroup 数据服务器中添加 HADR 的惟一方法是,为生产服务器和备用服务器都购买 High Availability Feature Pack!从 DB2 9.5 开始,不再需要这样做了,所以节省了资金:只需按照上述说明,作为 warm 服务器为 DB2 Workgroup 备用服务器颁发许可。

    另外,如果希望在 DB2 Express 数据服务器上使用 HADR,那么仍然必须购买 DB2 High Availability Feature Pack;但是,从 DB2 9.5 开始,不再需要在备用机器上为 High Availability Feautre Pack 颁发许可,除非将这台机器用作 HADR 孪生集群中的 hot 备用。

    最后,DB2 Express-C FTL 总是允许用 HADR 设置高可用性集群;这种配置没有许可方面的考虑事项,只需为安装 DB2 Express-C FTL 的每个服务器购买支持合约。


    原文链接:http://blog.csdn.net/jaminwm/article/details/4069005
    发布于 2年前, 阅读(90) | 评论(0) | 投票(0) | 收藏(0) 阅读全文...
  • 092012-03

          我写这篇文章是为了帮助您决定使用哪种分布式 DB2 版本来为您的企业提供动力。随着时间的推移,服务器版本不断变化,还应该注意,从 DB2 8 到 DB2 9 有许多变更,本文不讨论这些变更,以免本文过分复杂。在某些情况下,您可能拥有在 DB2 9 中不存在的特性或许可证。例如,DB2 8 Express Edition 要求购买一个服务器许可证和许多指定的用户权利,这样才能支持环境中的用户集。在 DB2 9 和更高版本中,在使用用户许可方式时没有服务器许可证。关于版本之间的变更、迁移和更新权利的信息.

          在与客户交谈时,常常有人问我许多关于高可用性的许可问题,或不同 DB2 版本之间的特性比较。关于这些主题和更多主题的详细信息,我曾经撰写的其他文章可能会有所帮助:

     

    DB2 具有公共的代码库
          在选择 DB2 版本来处理您的工作负载时,首先应该理解的是:除了 DB2 Everyplace® 和 Apache Derby(其 SQL API 与 DB2 完全兼容)以外,每个 DB2 版本对于不同的分布式平台都有相同的代码库。DB2 对于 Linux 的支持扩展到了所有的 IBM 服务器上:System i®、System z®、System x® 和 System p®,所有这些平台上的 DB2 也都是分布式版本。例如,DB2 for Linux on System z 与基于 Intel 或 AMD 的工作站上的 DB2 具有相同的代码库和许可方式。这意味着,尽管 DB2 for Linux on System z 服务器驻留在 System z 服务器上,但是访问数据并不需要 DB2 Connect。(请仔细理解这句话 —— 如果连接 System z 服务器上的 DB2 for z/OS 数据服务器,就需要 DB2 Connect;这里的差异在于 DB2 for Linux on a System z Integrated Facility for Linux(IFL)是一个分布式 DB2 版本。)

           公共的代码库提供了可移植性,并确保如果需要扩展 DB2 解决方案,就可以无缝地完成,而无需考虑成本、平台或迁移工作量;因为 DB2 系列中的 SQL API 大约 95% 是公共的,所以在 DB2 系列成员之间迁移也很容易。除了 SQL API 之外,还有其他兼容性特性。例如,有一个公共的 Web 服务框架,它允许通过鼠标单击将业务逻辑组合进面向服务体系结构(SOA)框架中。实际上,这个框架(称为 IBM Data Web Services)适用于所有 IBM 数据服务器,包括 Informix!尽管听起来不可思议,但是许多 IBM 数据服务器特性在每个 DB2 版本上都是相同的。例如,所有 IBM 数据服务器都用一个公共的 API 处理 SQL。例如,DB2 for z/OS 和 DB2 for Windows 的 JDBC 驱动程序具有相同的代码。还有一个公共的客户机:从 DB2 9.5 开始,如果要连接 DB2 for z/OS、DB2 for AIX 或 Informix,那么只需安装一个客户机。另外,应用程序开发和管理工具(比如 Visual Studio 集成或 IBM Data Studio)也对整个系列有效。在所有平台上都启用了 pureQuery。如果决定更改关于硬件体系结构(例如,从基于 Intel 的体系结构更改为 POWER6 体系结构)、操作系统(比如从 Windows® 迁移到 Linux™)或编程体系结构(比如从 .NET 更改为 Java,或反过来)的策略方向,就可以依赖于 DB2 适合各种平台这一特点。很简单,您可以自由地做出选择,而 DB2 确实是世界上惟一真正允许您根据环境定制信息平台的广度和深度的数据服务器。如果需要使用支持触发器、存储过程等功能的更强大的数据库,但是空间限制仍然很严格,而且设备可以运行 Java,那么也可以考虑使用 Apache Derby,它的内存占用量只有大约 2 MB。Apache Derby 数据库可以充当 DB2 Everyplace 环境中的同步客户机。另一个选择是 DB2 Express-C FTL

    DB2 Personal Edition……在个人平台上提供 DB2 的所有能力

          DB2 Personal Edition(DB2 Personal)是运行在基于桌面的普通硬件上的单用户数据服务器。DB2 Personal 可用在基于 Intel 和 AMD 的 Windows 和 Linux 工作站上。DB2 Personal 具有 DB2 Express Edition 中的大多数特性,但是它无法用作中心数据库服务器,因为远程客户机不能连接到这个 DB2 版本的数据库。但是,DB2 管理工具可以连接到这个 DB2 版本以执行远程管理。这个 DB2 版本还包含对 64 位实例的支持并且没有内存限制。DB2 Personal 提供安装 DB2 Net Search Extender 和 Spatial Extender 的权利(它们在 DB2 9 和更高版本中是免费的),还支持基于 SQL 的复制。复制特性可以与 DB2 数据服务器相结合以支持偶尔连接的工作人员,也可以用来创建自己的 “发布/订阅” 体系结构。DB2 Personal 还免费包含 pureXML 特性

    许可和定价

           DB2 Personal 按照安装发放许可证,这与大多数 PC 工作站软件非常相似。即使多位用户轮流使用同一个安装 DB2 Personal 的端点(他们显然无法同时工作,因为只有一台机器),仍然只需要一个许可证,因为它是按照安装而不是授权用户发放许可证的。DB2 Personal 的每个安装不需要考虑 RAM、价值单元等因素。例如,如果您有 10 个工作站,它们在三个 8 小时时间段中由 30 位用户平等地共享,那么需要 10 个 DB2 Personal 许可证。对于需要将个人单用户数据库用于大量 PC 工作站的应用程序来说,DB2 Personal 将是一个非常好的选择,可以在每个工作站上安装一个 DB2 Personal 拷贝。如果需要与分布式 DB2 数据服务器百分之百兼容,或者需要支持高级特性(比如 pureXML),那么 DB2 Personal 是比 DB2 Everyplace 和 Apache Derby 更合适的选择。偶尔连接的用户可能希望利用 DB2 Personal 内置的 SQL 复制特性来设置同步的数据和管理环境,在这种环境中移动的员工或远程服务器可以与他们的企业保持联系。当然,这只适合于膝上型计算机用户和某些工作站,例如那些运行销售点(POS)应用程序或销售自动化(SFA)应用程序的机器。最后,开发人员也常常使用 DB2 Personal —— 但是,我个人认为 DB2 Express-C 更适合开发人员。

    DB2 Express-C……它免费用于构建、开发和发布

          在 2006 年 1 月 30 日,IBM 发布了一个特殊的免费 DB2 数据服务器版本,它称为 DB2 Express-C。注意,它并不是 “正式的” DB2 版本。DB2 Express-C 是为合作伙伴和开发社区设计的,但是这个版本几乎可以在任何环境中使用。相比之下,一些免费的 Express 竞争产品不但对 RAM 和处理器设置了严格的限制,还限制了在线实用程序、数据库对象、自治、自动维护、内存位模型等,但是 DB2 Express-C 没有这么多限制。如果您研究这个 DB2 版本,会为它提供的丰富特性感到吃惊。DB2 Express-C 非常适合开发人员和中小型部署、学术社区等等。
       
    与 DB2 Express 相比,DB2 Express-C 中 不 包含的主要特性有:

        * 不保证代码。例如,对这个产品不提供支持,也不提供 DB2 Spatial Extender 等的下载。注意,仍然可以下载并使用免费的 DB2 Extender(DB2 Spatial Extender 和 DB2 Net Search Extender);但是,您要自己解决在使用这个 DB2 版本时遇到的问题。
        * 不能购买额外的 Feature Pack 来提供许多扩展服务。例如,不能购买 Storage Optimization Feature Pack,它提供深度行和备份映像压缩服务。但是您应该知道,DB2 Express-C 附带 pureXML 特性(稍后详细讨论),所以可以免费使用 DB2 XML 技术的所有功能。
        * 不能使用集群软件(比如 HACMP、SteelEye 或 DB2 9.5 内置的集群服务)将多台 DB2 Express-C 数据服务器配置成集群来提供高可用性。如果需要在高可用性环境中设置 DB2 Express-C,必须至少购买 DB2 Express-C Fixed Term License(FTL),FTL 是在这个 DB2 版本上增加的订购选项。
        * 没有复制服务。这个问题使许多人产生了混淆,因为以前的 DB2 Express-C 版本间接指出在这个包中可以使用 DB2 内置的 SQL 复制的 APPLY 组件。在 DB2 Express-C 中不能使用任何复制服务。
        * 不能购买获奖的 24x7 IBM Passport Advantage 支持模型,而收费的 DB2 数据服务器可以使用这个模型。这可能是 DB2 Express-C 最大的限制之一(不能设置高可用性数据服务器集群是另一个主要限制)。

          DB2 Express-C 的支持模型依赖于它的社区。这个社区的成员包括来自世界上最大型公司的最具经验的 DBA 以及众多的 DB2 开发人员和工程师,他们积极回答论坛上的提问,您可以在这里寻求 关于 DB2 Express-C 的帮助、建议和支持(这种方式就像是开放源码社区)。为了促进这个社区的发展,在 developerWorks Information Management 等网站上提供了实用的参考资料。
        * DB2 Express-C 只提供当前版本。换句话说,当一个 DB2 Express-C 新版本发布时,就不再提供老版本。

    如果希望使用上面列出的特性,至少需要购买 DB2 Express-C FTL(或者收费的其他 DB2 版本)。

    关于 DB2 Express-C 的好消息是对它的限制不多:没有数据库大小限制,没有自动管理或工具限制,没有内存模型限制(可以使用 64 位内存模型),等等 —— 您使用的就是纯正的 DB2。而一些 Express 竞争产品往往设置了许多限制;但是,这超出了本文的范围。

    DB2 Express-C 可以在运行 Linux 或 Windows 操作系统的服务器上使用。在 IBM DB2 Express-C 下载站点 上可以找到支持平台的完整列表。

    开发人员喜欢 DB2 Express-C,因为可以使用它免费开发和部署应用程序。ISV 也喜欢 DB2 Express-C,因为可以使用它免费开发 DB2 并在他们的打包应用程序中部署和发布 DB2。请牢记,因为 DB2 Express-C 是纯正的 DB2,这意味着可以不加修改地将这些应用程序部署到任何 DB2 版本上,甚至可以迁移到 DB2 for z/OS 上(只要在编写应用程序时使用 DB2 系列 95+% 的公共 SQL API 集)。

    许可和定价

    DB2 Express-C 可以免费构建、部署和发布。因此,这个 DB2 版本没有相关联的许可费用。但是,在任何规模的服务器上,它限制 DB2 引擎只能使用最多 2 GB 的内存和 2 个处理器核心。可以在虚拟化环境中使用 DB2 Express-C。

    DB2 9.5 中的变更

    以前的 DB2 Express-C 版本被限制为最多 4 GB 的内存和 4 个处理器插槽。用户负责通过 DB2 配置设置和个人观察实施这些限制。在 DB2 9.5 中,这些资源将遵循前一节描述的新限制。

    DB2 Express-C 可以用于许多不同的应用程序和项目 —— 尤其是因为它提供了收费 DB2 版本中的许多特性,而这些特性是其他 Express 竞争产品不具备的。

    DB2 Express-C Fixed Term License(Subscription)……它不但可以免费构建、开发和发布,还可以设置 HA,而且它提供了支持!

    在 2007 年 4 月 30 日,IBM 发布了另一个 DB2 Express-C 产品,DB2 Express-C Fixed Term License(FTL)。从本质上说,购买 DB2 Express-C FTL 会提供 DB2 Express-C 所不具备的三个特性:

        * 每个 DB2 Express-C FTL 数据服务器都包含 IBM 的 24x7 支持。这可以帮助您解决问题,并提供与 DB2 数据服务器匹配的维护计划。尽管这些服务器提供支持,但是仍然必须访问 DB2 Express-C 论坛 和 DB2 Express-C Web page on Developer's Domain,因为在这些网站上可以了解关于 DB2 的许多信息。
        * 与 DB2 Express-C 不同,DB2 Express-C FTL 为数据服务器增加了完整的 SQL 复制功能(包括 CAPTURE 和 APPLY 组件),因此适合偶尔连接的客户机或发布/订阅数据分布模型。
        * DB2 Express-C FTL 允许在高可用性环境中将多台 DB2 Express-C FTL 数据服务器设置成集群。在高可用性环境中设置 DB2 Express-C FTL 数据服务器集群时,无论以何种方式使用备用 DB2 Express-C FTL 数据服务器,必须为每台 数据服务器购买许可证;例如,cold、warm 或 hot 备用。更多信息请参考 为高可用性环境中的分布式 DB2 9.5 服务器颁发许可。
        * DB2 Express-C FTL 免费包含 High Availability Disaster Recovery(HADR)特性,这使建立高可用性 DB2 Express-C FTL 数据服务器集群的功能更加出众。
        * DB2 Express-C FTL 具有与常规 DB2 数据服务器更新计划相关联的 Fix Pack。例如,当为 DB2 发布一个 Fix Pack 时,也会为 DB2 Express-C FTL 提供这个 Fix Pack。另外,同时提供多个 DB2 Express-C FTL 版本,而 DB2 Express-C 只提供一个版本,不提供以前的代码库。

    DB2 Express-C 与 DB2 Express-C FTL 之间的差异

          当然,因为 DB2 Express-C FTL 的代码库与 DB2 Express-C 相同(各个 DB2 版本的代码库都相同),只是增加了前面提到的功能,所以仍然具备 DB2 Express 的灵活性和健壮性。与 DB2 Express-C 一样,也不能为 DB2 Express-C FTL 购买 Feature Pack;例如,不能购买 Storage Optimization Feature Pack,它提供深度行和备份映像压缩服务。因为 DB2 Express-C FTL 提供支持,所以仍然可以使用免费的 Extender 并获得相关支持 —— 您不必自己解决问题,IBM 支持团队会帮助您。可以在运行 Linux 或 Windows 操作系统的服务器上使用 DB2 Express-C FTL。在 IBM DB2 Express-C 下载站点 上可以找到支持平台的完整列表。

    许可和定价

          DB2 Express-C FTL 的 FTL 部分实际上是一个预订许可证。在为 DB2 Express-C FTL 购买许可证时,实际上是为 FTL 部分付费。这个预订提供一年的支持,还授权使用前面提到的附加功能。所以,在为这个产品发放许可证时,不需要考虑处理器、处理核心、VU 等因素。只需为每台服务器购买一个支持合同;例如,如果您有两台 DB2 Express-C FTL 数据服务器,那么必须购买两份预订(FTL)合同。如果使用 HADR 将这两台DB2 Express-C FTL 数据服务器组合成集群,那么仍然要购买两份预订合同,因为对于 DB2 Express-C FTL,没有与高可用性相关的特殊许可规则。如果在一台机器上的两个 VMWare 会话中安装 DB2 Express-C FTL,就必须购买两个 DB2 Express-C FTL 许可证。为 DB2 Express-C FTL 购买许可证很简单吧?您应该知道,在任何规模的服务器上,DB2 Express-C FTL 只能使用最多 4 个处理内核和 4 GB 的内存。

    DB2 9.5 中的变更

    以前的 DB2 Express-C FTL 版本被限制为最多 4 GB 的内存和 4 个处理器插槽。用户负责通过 DB2 配置设置和个人观察实施这些限制。在 DB2 9.5 中,这些资源将遵循前面小节描述的新限制。

    请考虑一下……

    DB2 Express-C FTL 可以用于许多不同的应用程序和项目 —— 尤其是因为它提供了收费 DB2 版本中的许多特性,而这些特性是其他 Express 竞争产品不具备的。如果您对 DB2 Express-C 满意,但是需要高可用性、复制、24x7 支持、pureXML 等附加特性,那么可以考虑使用 DB2 Express-C FTL。

    在 DB2 Express-C FTL 上可以实现的有趣功能

    因为这个产品刚发布不久,我还没有从客户那里了解到相关的反馈(只是到目前为止还没有)。但是,在免费数据服务器上提供 HADR、24x7 支持、复制和 pureXML 意味着什么呢?实际上大量生产性 OLTP 工作负载在两个插槽的机器上运行,现在可以以与 MySQL 相同的价格获得出色的可用性特性(HADR)、支持和 pureXML。这真的 很酷!

    DB2 Express Edition……简单、可靠且便宜

    DB2 Express Edition(DB2 Express)是一个入门级的具有完整支持的 DB2 数据服务器,是专门定制的廉价、特性完整、达到工业级别和基于开放行业标准的关系数据库。这个 DB2 版本的目标用户通常是 SMB(中小型企业)和 ISV。对于使用运行 Linux、Solaris x86 和 Windows 的服务器的企业,DB2 Express 提供了非常诱人的切入点和富有竞争力的价格(前面的链接提供最新的平台支持信息)。

    DB2 Express 还提供了大量可供选择的业务伙伴应用程序、服务和支持。它附带一组定价计划,合作伙伴可以利用这些计划为其企业产生可观的收入。当然,企业也可以选择在其环境中部署 DB2 Express,并且也经常这样做。

    因为 DB2 Express 的核心是功能完整的 DB2 服务器(在这里找不到其他竞争产品中存在的技术性限制),所以 DBA 可以利用其内置的自主可管理性特性,如 IBM 的 Self Tuning Memory Manager(STMM)、Configuration Advisor、Health Center、Design Advisor、自主维护计划、自动备份调优和节流以及更多功能。这些服务有助于提高 DB2 解决方案的性能和可靠性,同时将管理复杂性、所需的技能和总拥有成本降到最低。

    DB2 Express 支持高可用性(HA)体系结构,如 HA 集群技术和日志传送。DB2 9.5 中内置的 Tivoli System Automation(TSA)可用性技术和 HADR 不包含在基本的 DB2 Express 版本中,但是可以通过 Feature Pack 单独购买这些特性(稍后详细讨论)。考虑到其他以 SMB 为目标的流行数据库仅仅在其高级版本中包含高级在线和管理功能,加之 DB2 Express 的价格和自主功能,您可能从来不曾知道 DB2 Express 的存在,而且还可以包含在您的笔记本中!

    这个 DB2 版本与用于 Linux、Windows 和 UNIX 平台的其他可伸缩 DB2 关系数据库产品完全兼容,您可以预先配制 DB2 Express,以便轻松透明地安装到应用程序中。客户会喜欢 DB2 Express,因为他们所看到的全部东西只是一个解决方案;业务伙伴也会喜欢它,因为他们可以信任它能够在真正无人值守的情况下运行。

    DB2 Express 附带 DB2 Net Search Extender(在所有 DB2 9 版本中都是免费的)、Spatial Extender(在所有 DB2 版本中也是免费的)以及基于 SQL 的复制。

    关于 DB2 Express 特别好的一点是,它具有 “企业可扩展性”。有许多 Feature Packs 可以添加到 DB2 Express 数据服务器上,从而用企业服务充实它的功能。同时,仍然可以享受这个 DB2 版本的低价格。设计这些附加 Feature Pack 的目的是避免中端市场解决方案被迫使用企业级产品,而市场上的其他竞争产品会出现这一问题。

    DB2 Express 数据服务器的 Feature Pack

    可以通过购买 Feature Packs,用许多企业服务扩展 DB2 Express。Feature Pack 是在 DB2 9 中首次引入并在 DB2 9.5 中继续更新。通过引入 Feature Pack,客户可以按照菜单定制 方式为应用程序购买数据服务,应用程序就可以在不使用大型服务器的情况下,使用通常在成熟的企业解决方案中才有的服务。

    Feature Pack 必须采用与 DB2 数据服务器相同的许可方式,也就是按照授权用户许可证或者按照安装它们的服务器的价值单元级别授予许可。DB2 Express 9.5 可用的 Feature Pack 有变化,包括:

        * High Availability Feature for DB2 Express: 它提供的许多服务可以提高在 DB2 Express 数据服务器上运行的应用程序的可用性,包括支持在线表重组、用于 DB2 9.5 内置的 Tivoli System Automation(TSA)高可用性服务的两节点集群许可证和 High Availability Disaster Recovery(HADR)。这个 Feature Pack 中的所有特性都包含在基本 DB2 Workgroup 和 DB2 Enterprise 版本中。

          HADR 是一组可用性服务,它们提供可靠的数据库可用性和一个保护计划,不但在整个组合上提供冗余,甚至能够满足最苛刻的可用性服务水平协议,支持以秒度量的平均修复(MTTR)时间。HADR 最出色的方面是,只需单击按钮,就能够设置好它。

          在线表重组与其他厂商的产品功能都不一样。它可以对表进行连续的重组,而不需要传统镜像复制方式所需的大量磁盘空间。它可以启动、暂停和节流;当您改变操作的状态时,就立刻会见到收益。例如,可以在晚上运行重组,在白天对它进行节流或停止它。当重组停止时,访问表的应用程序会立即享受到重组带来的好处:这是真正的可用性。

          DB2 9.5 将 TSA 高可用性技术集成在 DB2 中。可以利用这些服务将两个数据服务器设置成高可用性集群,甚至自动执行 HADR 解决方案的故障转移。除此之外,DB2 9.5 安装程序可以自动配置高可用性集群。还有一个新的框架,它的前端是新的 DB2 High Availability Instance Configuration Utility(db2haicu)。这个框架提供一个基于文本的界面,可以使用它在集群环境中配置和管理高可用性数据库。现在,DB2 可以通过查询系统收集关于数据库实例、集群环境和集群管理器的信息,还可以让整个集群在发生变化时保持同步。
        * pureXML for DB2 Express: 它允许在 DB2 Express 数据库中创建 pureXML 列和使用相关的 XML 服务,比如 XML 模式检验和注册服务、基于路径的索引服务、XQuery 服务等。注意,DB2 Personal、DB2 Express-C 和 DB2 Express-C FTL 免费提供这个特性。

          尽管 DB2 XML Extender 的效率和功能不及 DB2 9 中的 pureXML 服务,但是 DB2 9.5 中仍然提供它,可以使用它对 XML 进行持久化。但是您应该知道,XML Extender 存储 XML 的方式与其他关系数据库产品相同:即把 XML 数据分解成关系格式,或者将整个 XML 文档放进一个大对象中。无论您使用哪个厂商的数据库,在使用他们的技术对 XML 数据进行持久化时,都需要在性能、灵活性等方面进行权衡。

          DB2 9.5 中的 pureXML 特性提供的服务不会在存储 XML 数据时损害灵活性(灵活性是设计 XML 的目的)和性能(性能是用数据服务器存储 XML 的原因之一)。对于几乎所有基于 XML 的应用程序,强烈建议使用这个特性。
        * Homogeneous Federation for DB2 Express :它允许跨 DB2 系列成员创建别名。这样,应用程序就能够使用驻留在不同平台上的 DB2 表,而不用考虑它们的位置。例如,可以使用这个特性对驻留在 DB2 for i5/OS 数据库中的数据和 DB2 for Linux on System z 中的数据执行联结。如果希望对非 IBM 数据源执行联邦操作,或者希望使用基于队列的复制,那么需要购买单独的 IBM Information Server 套件 中的产品。

    许可和定价

    DB2 Express 对于安装它的服务器有以下体系结构限制:

        * DB2 Express 要求整个数据服务器使用的内存不超过 4 GB。尽管有这个内存限制(用一个配置参数控制),但是可以在内存超过 4 GB 的服务器上安装 DB2 Express —— 这个限制是要求 DB2 数据服务器软件 使用的内存不超过 4 GB。例如,如果在一个有 8 GB 内存的服务器上安装两个数据库,那么可以在这两个数据库之间分配 4 GB 内存(即使它们在不同的实例中),但是物理服务器上所有实例和数据库的内存总和不能超过 4 GB。还要牢记一点:这个限制是软性实施的 —— 换句话说,由您负责确保数据服务器不超过这个限制,因为 DB2 Express 并不像 DB2 Express-C 和 DB2 Express-C FTL 那样硬性限制这个资源。
        * 只能在小于等于 200 VU 的服务器上安装 DB2 Express。例如,因为一个双核 x86 Intel 处理器的每个处理核心是 50 VU,所以在安装这个 DB2 版本的服务器上最多只能有两个双核 x86 Intel 处理器。
        * 这个 DB2 版本不支持子容量许可。

    可以按照以下两种方式之一为 DB2 Express 数据服务器购买许可证:

        * 按照安装 DB2 Express 软件的服务器的 价值单元 总数购买许可证。这种许可证允许任意数量的用户使用任何方法访问 DB2 Express 数据服务器。
        * 按照访问 DB2 Express 数据服务器的授权用户总数购买许可证。授权用户是一个个体(在某些情况下,只要不代表其他用户发挥作用,它可以是一个应用程序或装置),它具有在公司内外的特定身份。由于最终用户是已知的(必须针对许可明确识别用户),因此也可以通过因特网使用这些许可证(比如在线银行应用程序)。授权用户许可证拥有完全的权利;不需要像以前的 DB2 版本中那样另外使用服务器许可证。请注意特定身份 这个词。如果使用多路复用或连接集中软件,那么需要首先完全识别这些用户,然后才能将这些软件应用于连接。

          对于访问数据服务器的每个用户,都需要获得一个授权用户许可证;但是,无论有多少用户访问数据服务器,至少要购买最低数量 的授权用户许可证:每个 DB2 Express 服务器要求最少 5 个授权用户许可证。

          授权用户许可证不能随工作转移而转移(但是可以由于雇用关系转移而转移),它们只对特定的一个服务器有效。例如,如果有 25 个用户需要访问两个单独的 DB2 Express 数据服务器,那么需要购买 50 个授权用户许可证:2 个服务器 x 每个服务器 25 个授权用户。即使这些用户中只有 12 个用户同时连接数据服务器,仍然必须为每个数据服务器购买所有 25 个用户的许可证(所以这个示例需要 50 个授权用户许可证)。如果有一个 DB2 Express 数据服务器且只有 3 个用户,那么仍然需要购买 5 个 DB2 Express 授权用户许可证,这样才能满足这个 DB2 版本对最低用户数的要求。

    DB2 9.5 中的变更

    DB2 9.5 并没有改变 DB2 Express 的定价或许可规则。但是,从 DB2 9.5 开始,取消了 DB2 Express 可用的一些 Feature Pack,只保留前一节中提到的那些 Feature Pack。具体地说,不能为 DB2 Express 9.5 购买 Workload Management 和 Performance Optimization Feature Packs,不能在这个 DB2 版本中使用其中包含的特性。

    请考虑一下……

    DB2 Express 是一个入门级的 DB2 数据服务器,对于不需要超过 4 GB 内存和 200 VU 处理能力的工作负载,应该考虑使用这个版本。这个版本不适合那些需要并行性或 MDC 表等可伸缩性特性的应用程序,因为基本 DB2 Express 服务器不提供这些特性,也无法通过 Feature Pack 获得它们。

    在 DB2 Express 上可以实现的有趣功能

    Sage 是世界上最著名的端到端软件提供商之一,运行 SMB 等业务。在默认情况下,他们的 ACCPAC 应用程序在 DB2 Express 上运行。Craig Downing(负责产品管理的副总裁)指出,“DB2 清楚地表明 IBM 的产品很适合 SMB 市场。尤其是,管理任务的自动化使中小型企业能够获得很高的数据可靠性,同时不需要在管理方面做很多工作。”

    一家为北美的 280 万中小用户(和全世界的 450 万用户)服务的公司选用 DB2 Express 来处理他们最流行的应用程序之一,因为 DB2 Express 容易使用。这真的很酷!

    DB2 Workgroup Server Edition……它比 DB2 Express 大一点儿,但并不悬殊

    DB2 Workgroup Server Edition(DB2 Workgroup)是提供与 DB2 Express 数据服务器相同的功能的 DB2 数据服务器,但它是为需求更高的工作负载设计的,支持更多内存、更大处理能力和更高的可用性,并提供许多平台部署选项。与 DB2 Express 不同(DB2 Express 只能在 Windows、基于 x86 的 Solaris 和 Linux 操作系统上运行),在 DB2 支持的所有分布式平台上都可以运行这个 DB2 版本,即:Linux、Windows、AIX、Solaris 和 HP-UX(前面的链接提供最新的平台支持信息)。

    DB2 Workgroup 在功能方面与 DB2 Express 相似;但是从 DB2 9.5 开始,它免费包含 High Availability Feature Pack 的所有组件(在 DB2 Workgroup 9 中,这是付费组件)。具体地说,从 DB2 9.5 开始,基本 DB2 Workgroup 版本包含 HADR、在线表重组和集成的 TSA 高可用性软件。除此之外,DB2 Express 和 DB2 Workgroup 在 RAM 和价值单元限制方面也不同;与 DB2 Express 相比,可以用来丰富 DB2 Workgroup 数据服务器的 Feature Pack 更多。

    DB2 Workgroup 数据服务器的 Feature Pack

    与 DB2 Express 一样,可以通过购买 Feature Packs,用许多企业服务扩展 DB2 Workgroup。DB2 Workgroup 可用的 Feature Pack 比 DB2 Express 多,所以 DB2 Workgroup 可以提供比 DB2 Express 更多的附加功能和选项。

        * Query Optimization Feature for DB2 Workgroup: 这个 Feature Pack 以前在 DB2 9 中称为 Performance Optimization Feature Pack,它支持在 DB2 Workgroup 数据服务器上使用物化查询表(MQT)、多维聚簇(MDC)表和查询并行性。所有这些特性都用来提供出色的性能(尤其适合商业智能化 [BI] 应用程序),它们是基本 DB2 Enterprise 版本的组成部分。在 DB2 Express 中不能使用这个 Feature Pack。

          DB2 提供许多高性能对象和功能,可以将处理能力提高到每分钟处理数十万个用户和数百万个事务。这个 Feature Pack 支持在 DB2 Workgroup 数据服务器中创建 MDC 表和 MQT。这些对象可以为 DB2 上运行的应用程序提供很大的好处。实际上,我认为这个 Feature Pack 包含了对于任何高性能 BI 应用程序最重要的一些组件。(如果将 DB2 用于 BI 应用程序,就一定要了解 MDC 和 MQT 是什么。)如果您希望大大提高在 DB2 Workgroup 和小型服务器上运行的应用程序的性能,那么这个 Feature Pack 正好提供了您需要的组件。
        * pureXML for Workgroup:为 DB2 Workgroup 提供与 pureXML Feature Pack for DB2 Express 相同的 XML 特性和功能。
        * Homogeneous Federation DB2 Workgroup:为 DB2 Workgroup 提供与 Homogeneous Federation DB2 Express 相同的同构联邦特性和功能。

    许可和定价

    在核心功能方面,DB2 Workgroup 和 DB2 Express 差不多是相同的产品,只是在 DB2 9.5 中 DB2 Workgroup 免费包含 High Availability Feature Pack。在许可方面,这两个 DB2 版本的差异在于体系结构限制:

        * DB2 Workgroup 数据服务器限制为 16 GB 内存。由您负责用与内存相关的配置参数管理这个限制。这意味着可以在内存超过 16 GB 的服务器上安装 DB2 Workgroup —— 这个限制是要求 DB2 数据服务器软件 使用的内存不超过 16 GB。例如,如果在一个有 32 GB 内存的服务器上安装两个数据库,那么可以在这两个数据库之间分配 16 GB 内存(即使它们在不同的实例中),但是物理服务器上所有实例和数据库的内存总和不能超过 16 GB。
        * 只能在小于等于 400 VU 的服务器上安装 DB2 Workgroup。
        * 在 DB2 Workgroup 软件中不能使用子容量许可。

    可以按照以下两种方式之一为 DB2 Workgroup 购买许可证:

        * 按照安装 DB2 Workgroup 软件的服务器的 价值单元 总数购买许可证。这种许可证允许任意数量的用户使用任何方法访问 DB2 Workgroup 数据服务器。
        * 按照访问 DB2 Workgroup 数据服务器的授权用户总数购买许可证。授权用户是一个个体(在某些情况下,只要不代表其他用户发挥作用,它可以是一个应用程序或装置),它具有在公司内外的特定身份。由于最终用户是已知的(必须针对许可明确识别用户),因此也可以通过因特网使用这些许可证(比如在线银行应用程序);不需要像以前的 DB2 版本中那样另外使用服务器许可证。请注意特定身份 这个词。如果使用多路复用或连接集中软件,那么需要首先完全识别这些用户,然后才能将这些软件应用于连接。

          对于访问数据库的每个用户,都需要获得一个授权用户许可证;但是,无论有多少用户访问数据服务器,至少要购买最低数量 的授权用户许可证:每个 DB2 Workgroup 服务器要求最少 5 个授权用户许可证。

          授权用户许可证不能随工作转移而转移(但是可以由于雇用关系转移而转移),它们只对特定的一个服务器有效。例如,如果有 25 个用户需要访问两个单独的 DB2 Workgroup 数据服务器,那么需要购买 50 个授权用户许可证:2 个服务器 x 每个服务器 25 个授权用户。即使这些用户中只有 12 个用户同时连接数据服务器,仍然必须为每个数据服务器购买所有 25 个用户的许可证(所以这个示例需要 50 个授权用户许可证)。如果有一个 DB2 Workgroup 数据服务器且只有 3 个用户,那么仍然需要购买 5 个授权用户许可证,这样才能满足这个版本对最低用户数的要求。

    DB2 9.5 中的变更

    DB2 9.5 在许可和打包方式方面做了许多重要(且具有积极意义)的变更。在许可方面,DB2 Workgroup 9.5 的 RAM 限制针对数据服务器,而不是像 DB2 9 中那样针对物理服务器。这使公司能够在更大的服务器上运行 DB2 Workgroup,使这个 DB2 版本更适合参与多应用程序整合。注意,DB2 9.5 的 RAM 限制并没有变,只是改变了计算方法。很简单,从 DB2 9.5 开始,如果服务器不超过 400 VU 而且服务器上有 32 GB 的 RAM,就可以使用 DB2 Workgroup(只要 DB2 只使用 16 GB 的 RAM);而在 DB2 9 中就不能这么做。

    DB2 9.5 中的另一个重要变更是,High Availability Feature Pack 不再作为 DB2 Workgroup 的可选 Feature Pack。那么,它放在哪里了?它免费包含在这个产品中!从 DB2 9.5 开始,HADR、在线表重组和集成的 TSA 集群软件等特性包含在 DB2 Workgroup 中。当然,如果将两个 DB2 Workgroup 服务器设置成高可用性集群,那么仍然必须根据备用服务器的角色为它购买许可证。注意,DB2 9.5 将描述备用服务器的术语从 active/passive 改为 hot/warm/cold,还引入了一些新的许可规则。正如前面提到的,我的文章 “为高可用性环境中的分布式 DB2 9.5 服务器颁发许可” 讨论了这些细节;同样,这些变更都有积极意义。

    除了在 DB2 Workgroup 9.5 中免费包含 High Availability Feature Pack 之外,对于这个 DB2 版本,还取消了一些 Feature Pack,一些 Feature Pack 改了名字。Workload Management Feature Pack 不再作为这个版本的可选 Feature Pack。这意味着这个 DB2 版本不能再使用 DB2 Query Patroller、DB2 Governor 和替代它们的 Workload Manager。

    最后,在 DB2 9 中,可以为 DB2 Workgroup 购买 DB2 Performance Optizmiation Feature Pack。这个 Feature Pack 包含 MDC、MQT 和并行性。DB2 Workgroup 现在仍然可以使用这个 Feature Pack,但是它已经改名为 Query Optizmization Feature Pack;但是,它提供的组件是相同的。改变它的名称是为了避免混淆,因为 DB2 Enterprise 可用的一个 Feature Pack 使用同样的名称,但是包含不同的组件。

    请考虑一下……

    DB2 Workgroup 可以在企业中扮演许多角色。如果中小型企业需要完全成熟的可伸缩且高可用的关系数据库,但是数据服务器不需要使用 16 GB 以上的内存或超过 400 VU 的处理能力,那么很适合使用这个版本。与 DB2 Express 相比,DB2 Workgroup 尤其适合业务线应用程序需要小型 “silo” 服务器的企业环境,也适合需要为低事务吞吐量应用程序提供企业服务的部门。

    DB2 Enterprise Server Edition……无可匹敌的可伸缩性、弹性和灵活性

    DB2 Enterprise Server Edition(DB2 Enterprise)是 IBM 功能最齐全的支持 Web 的客户机/服务器数据服务器。在 DB2 支持的所有分布式平台上都可以运行这个 DB2 版本,即:Linux、Windows、AIX、Solaris 和 HP-UX(前面的链接提供最新的平台支持信息)。

    DB2 Enterprise 旨在用作大中型的部门服务器,在所有 DB2 9 版本中它提供的特性和服务最为全面。例如,这个 DB2 版本免费提供表分区、HADR、并行性、MDC、MQT、TSA 等服务,而这些特性对于 DB2 Express 和 DB2 Workgroup 需要通过 Feature Pack 另外购买。除此之外,DB2 Enterprise 还具备它特有的服务。例如,DB2 Enterprise 能够使用表分区服务对一台服务器中的数据进行分区,这个服务只能在 DB2 Enterprise 上使用。这个功能包含在基本 DB2 Enterprise 版本中,但是对于 DB2 Express 或 DB2 Workgroup 都不可用,甚至无法通过 Feature Pack 购买。

    这个 DB2 版本对于使用的内存数量没有限制(实际上,最好的 DB2 9 TPC-C 结果使用差不多 2 TB 内存作为缓冲池 —— 这个内存量甚至超过了许多公司拥有的数据总量)。对于运行这个数据服务器的底层服务器,也没有最大 价值单元 限制。

    DB2 Enterprise 还有一组 Feature Pack,它们可以用更多的数据服务扩展企业解决方案。

    DB2 Enterprise 数据服务器的 Feature Pack

    DB2 Enterprise 有自己的一组 Feature Packs,它们为 DB2 Enterprise 提供高级数据服务,可以按照与 DB2 Express 和 DB2 Workgroup 数据服务器相同的方式使用这些 Feature Pack。因为 DB2 Express 和 DB2 Workgroup 的 Feature Pack 提供的许多服务免费包含在 DB2 Enterprise 中,所以这个 DB2 版本可用的大多数 Feature Pack 与那两个版本不一样。

    DB2 Enterprise 的 Feature Pack 必须采用与 DB2 Enterprise 数据服务器相同的许可方式,也就是按照授权用户或者按照价值单元购买许可证。但是,DB2 Storage Optimization Feature Pack 不能使用授权用户许可证,必须按照价值单元购买许可证。这意味着,如果要购买这个 Feature Pack,那么 DB2 Enterprise 也必须使用价值单元许可证。

    在 DB2 Enterprise 中可用的 Feature Pack 有:

        * Performance Optimization Feature for DB2 Enterprise: 它提供工作负载管理服务和一套用于 DB2 数据服务器性能调优的报告和工具。

          DB2 9.5 引入了一组全新的工作负载管理服务,它们替代了以前由 DB2 Query Patroller 和 DB2 Governor 组成的体系结构;这些服务统称为 Extreme Workload Manager 或 DB2 Workload Manager(DB2 WLM)。DB2 9.5 中的这个新体系结构允许显式地控制执行的工作的 CPU 使用,探测并防止所谓的 run away 或 rogue 查询,以许多不同的方式密切监视数据库活动。

          DB2 WLM 可以替代以 DB2 Query Patroller 和 DB2 Governor 为中心的 DB2 9 工作负载管理解决方案。在 DB2 9.5 中仍然完全支持这两个产品,并可以在 DB2 9.5 WLM 环境中使用它们;但是,它们将随着时间的推移逐渐退出,最终将被 DB2 WLM 取代。

          Performance Optizmiation Feature Pack 还包含 DB2 Performance Expert。DB2 Performance Expert 简化了性能管理和调优工作。它为 DBA 提供 DB2 数据服务器的一致性视图,包含关于实例、子系统、数据库和应用程序的信息。例如,它提供一组预定义的报告,可以显示 DB2 中的资源不足和异常情况、锁冲突和死锁以及导致高工作负载的应用程序和 SQL 语句。它还包含一组关于 SQL、数据库和缓冲池活动的详细报告,并进行趋势分析和假设测试,从而支持性能优化等任务。这个 Feature Pack 中的 DB2 Performance Expert 版本只能供在 Linux、UNIX 和 Windows 上运行的 DB2 数据服务器使用,而在这个 Feature Pack 之外另外购买的 DB2 Performance Expert 工具可以在所有 DB2 系列产品上使用。
        * pureXML for DB2 Enterprise:为 DB2 Enterprise 提供与 pureXML Feature Pack for DB2 Express 相同的 XML 特性和功能。
        * Homogeneous Federation DB2 Enterprise:为 DB2 Enterprise 提供与 Homogeneous Federation DB2 Express 相同的同构联邦特性和功能。
        * Advanced Access Control for DB2 Enterprise: 它为 DB2 Enterprise 数据服务器中存储的数据提供基于标签的访问控制(LBAC)保护服务。通过使用这个特性,可以在表列和行级别控制用户和组拥有的读写访问权。LBAC 通过在表对象上附加安全标签来控制对它们的访问。试图访问对象的用户必须具有安全标签。如果安全标签匹配,就允许访问;如果不匹配,就拒绝访问并隐藏数据。

          Advanced Access Control 特性提供一个安全框架,可以围绕业务实体、数组或其组合的层次化表示组织这个框架。除此之外,还可以使用 LBAC 在文档级控制对 pureXML 列中存储的 XML 文档的访问。
        * Geodetic Data Management Feature: 它提供考虑到地球曲率的空间分析(这是它与所有 DB2 9 版本中的免费 Spatial Extender 之间的主要差异)。Geodetic Data Management Feature 用于那些需要把地球表面投影所造成的误差减至最低的高级分析,它对于国防应用程序、天气应用程序等尤其有用。

          例如,在使用 DB2 Spatial Extender 时,可以用不同的投影(例如,Mercator 投影)使地球 “平面化”,然后在应用程序中容忍或考虑误差。如果用这种方法定位打 911 报警电话的人的住宅,那么不会产生什么问题(10 英尺的误差不会造成什么损害)。但是,像导弹防御系统这样的国家安全应用程序需要更高的精度,无法容忍将地球表面 “平面化” 为 LAT/LONG 坐标所导致的误差。这正是 Geodetic Data Management Feature 可以发挥作用的领域。

          通俗地讲,如果诸如 “格陵兰岛是非洲的 1/14”(这与我在上小学时看到的地图并不符合)这样的误差会给应用程序带来问题,那么这个特性正好适合您。
        * Mobility on Demand for Enterprise :它以低价为 DB2 Enterprise 服务器提供 DB2 Everyplace Enterprise 的组件。通过使用这个特性,可以把企业数据扩展到数量不限的移动设备上(只要这些设备能够与数据服务器进行数据同步)。
        * DB2 Storage Optimization Feature for DB2 Enterprise :它提供的存储压缩服务可以用来优化数据的性能和内存占用量。这个 Feature Pack 由 Row Level Compression 和 Backup Compression 服务组成。

          Row Level Compression 服务是在 DB2 9 中首次引入的,它给数据库行业带来了很大的震撼。在 DB2 9.5 中,它们得到了扩展,支持自主的词典创建。这些服务提供从磁盘到缓冲池的行级压缩,可以显著减少磁盘空间占用(内部测试表明,这些服务节约的磁盘空间平均为大约 65%),并提高出现 I/O 瓶颈的系统的性能(数据仓库系统的瓶颈都在 I/O 方面;毕竟,CPU 瓶颈是很容易消除的)。但是,不只如此。

          请考虑一下压缩可能带来的其他潜在好处。相信我,压缩的好处绝不仅仅是节约磁盘空间。例如,在 DBA 必须负责的备份任务方面,压缩不但使备份更小,而且备份过程会更快(因为要备份的数据更少)。再想想 Q/A 和测试环境。如果数据在磁盘和 内存缓冲区中都是压缩的,那么就可以在这些缓冲区中获得更多数据。这不仅意味着性能可能会提高,而且 RUNSTATS 和 REORG 等维护操作也可以更快地运行。另外,考虑到 DB2 9 可以在一个数据页面上支持超过 2,000 个数据行(DB2 8 限制为 255 个数据行),您已经拥有了一个出色的消除 I/O 瓶颈的方法。最后,考虑 HVAC 给存储等方面带来的好处。综合考虑所有这些因素之后,您就会相信对数据进行压缩的好处绝不仅仅是节约磁盘空间,它将会全面改善系统!

          那么,DB2 9 中的这些压缩服务有哪些与众不同之处呢?InfoWorld 上提供的访谈对 DB2 9 做了以下评论:“DB2 中新的行级压缩是我最喜欢的特性之一。它实际上是表级压缩,可以直接节省 45% 到 75% 的磁盘空间……如果要我选出比其他任何数据库都先进的 DB2 特性,那么这个特性肯定是其中之一,因为它对大多数客户都很有帮助。我想 Oracle 和 Microsoft 正在努力将这一特性引入市场。”

          顾名思义,Backup Compression 服务可以对数据库备份进行压缩。DB2 中的数据库备份框架基于一个开放的可插入接口,它允许使用 DB2 附带的默认压缩算法,也可以使用您自己的算法。使用的压缩算法嵌入在备份映像中,所以在发生灾难后恢复数据时,可以在另一个服务器上恢复数据。

    许可和定价

    可以按照以下两种方式之一为 DB2 Enterprise 购买许可证:

        * 按照运行这个软件的服务器的 价值单元 总数购买许可证。这种许可证允许任意数量的用户使用任何方法访问 DB2 Enterprise 数据服务器。但是要注意,与 DB2 Express 和 DB2 Workgroup 不同,DB2 Enterprise 可以进行子容量定价。例如,可以在 System p 服务器上创建一个 LPAR,让它使用服务器上的一半价值单元,然后按照这些价值单元(而不是整个服务器的价值单元数)为 DB2 Enterprise 购买许可证。另外,可以按照 Dynamic LPAR(DLPAR)为 DB2 Enterprise 购买许可证,DLPAR 中的资源根据预定义的业务规则动态地移入和移出安装 DB2 的 LPAR。可以通过我的文章 “DB2 Universal Database 在双核心处理器和随需添加处理器上的许可授权” 了解如何在 LPAR 或 DLPAR 环境中为 DB2 购买许可证;尽管这篇文章根据内核数量进行讨论,而 IBM SWG 现在按照 VU 进行软件定价,但是判断许可需求的方法是相同的。
        * 按照访问 DB2 Enterprise 数据服务器的授权用户总数购买许可证。授权用户是一个个体(在某些情况下,只要不代表其他用户发挥作用,它可以是一个应用程序或装置),它具有在公司内外的特定身份。由于最终用户是已知的(必须针对许可明确识别用户),因此也可以通过因特网使用这些许可证(比如在线银行应用程序)。授权用户许可证拥有完全的权利;不需要像以前的 DB2 版本中那样另外使用服务器许可证。请注意特定身份 这个词。如果使用多路复用或连接集中软件,那么需要首先完全识别这些用户,然后才能将这些软件应用于连接。

          与 DB2 Express 和 DB2 Workgroup 一样,DB2 Enterprise 也有最低授权用户许可证数量要求。DB2 Express 和 DB2 Workgroup 要求为每个服务器至少购买 5 个授权用户许可证,而 DB2 Enterprise 要求为服务器上的每 100 VU 购买至少 25 个授权用户许可证。应该注意,对于每个服务器,都有一个授权用户许可证数量的 “平衡点”;在这个位置上按照 VU 为服务器购买许可证会更划算。

          例如,如果在一台基于 IBM Power 5 QCM 的 System p 服务器上运行 DB2 Enterprise,服务器有一个四核处理器,您至少需要购买 50 个用户许可证,因为这台服务器的 VU 总数是 200 VU(200 VU/ 100 VU = 2 x 25 授权用户)。如果在一台 Sun Niagara 服务器上运行 DB2 Enterprise,服务器有一个六核处理器,则至少要购买 50 个授权用户许可证,因为这台服务器的 VU 总数是 180 VU,当超过 100 VU 阈值时,VU 总数应该向上取整到 100 VU 的倍数。当然,如果使用 LPAR 技术,计算 DB2 许可证所用的 VU 数量就不一样了。

          授权用户许可证不能随工作转移而转移(但是可以由于雇用关系转移而转移),它们只对特定的一个服务器有效。例如,如果有 75 个用户需要访问两个单独的 DB2 Enterprise 数据服务器,那么需要购买 150 个授权用户许可证:2 个服务器 x 每个服务器 75 个授权用户 = 150(每个服务器 75 个)。但是,如果这两个服务器都有 4 个基于 Intel XEON 的双核处理器,那么需要购买最少 200 个授权用户许可证(每个服务器 100 个),因为 DB2 Enterprise 的最低授权用户数量要求是每 100 VU 25 个用户:((( 4 个插槽 x 2 个核心 = 8 个核心 ) x 每个核心 50 VU = 400 VU)/100 VU = 4) x 25 个授权用户 = 100 x 2 个服务器 = 200 个授权用户。

    DB2 9.5 中的变更

    Database Partitioning Feature(DPF) 不再作为 DB2 Enterprise 的 Feature Pack。这个特性没有取消,但是因为它适用于数据仓库,所以被包含在所有 DB2 Warehouse 版本中。

    请考虑一下……

    如果应用程序需要无限制的灵活性(例如,使用表分区)和可伸缩性(例如,没有 VU 或 RAM 限制),那么应该认真考虑使用 DB2 Enterprise。如果需要高级的扩展服务,例如高级的安全控制服务(比如基于标签的访问控制)、存储优化服务(比如压缩)等,那么也应该考虑使用 DB2 Enterprise。DB2 Enterprise 对于容量没有限制,您只需考虑优化资源平衡,而且它提供大量特性。

    DB2 Data Stream Edition

    DB2 Data Stream Edition(DB2 Data Stream,也称为 DB2 Real Time Insight) 是一种综合的服务、特性和产品组合,其中包含 DB2 Enterprise、Data Partitioning Feature 和 Real-Time Insight Feature。它提供一个快速且高效的内存数据服务器,并包含处理实时数据流的扩展服务。

    是把它称为一个 DB2 版本,还是一个 DB2 特性?对于这个问题,我犹豫了很久。因为它的核心实际上是 Real-Time Insight Feature(这个特性只能通过这个产品使用)。我决定把它称为一个版本,因为它实际上是针对一种特殊应用程序类型的解决方案。

    越来越多的客户需要捕捉并存储由电子源生成的大量实时 数据,比如市场数据 feed、GPS 发送器生成的地理位置、RFID 标记生成的产品 ID 等等。设计 DB2 Data Stream 就是为了满足这种需求。这些数据通常很小,但是量(消息数量)非常庞大。例如,市场数据提要常常出现每秒超过 100,000 个事务的情况!

    促使为这种应用程序购买 DB2 Data Stream 的主要业务因素是,它们是需要严格优化和加强的应用程序。例如,军事、供应链(旅行推销员问题)、技术公平贸易战略、后勤计划等领域都可能需要处理大量的流数据。用于处理风险、国内贸易、人身安全或反恐的应用程序也是这种应用程序的好例子。

    DB2 Data Stream 为处理各种消息提供了很大的灵活性,它为长期持久化和后继过程中的操作提供服务,对后继的分布操作进行筛选,比如删除、可行的纠正或否决等操作。这个产品的细节超出了本文的范围,如果您需要这种解决方案,请通过 IBM 销售代表和 IBM 业务伙伴了解更多信息。

           对于应用程序开发而言,可使用名为 Database Enterprise Developer's Edition(DEDE)的特殊产品。这是一个降价产品,它使应用程序开发人员可以访问大多数 DB2 特性和版本,以及一组 Informix 产品和 DB2 Connect。DEDE 仅限于应用程序的开发、评估、演示和测试用途。DEDE 是按每个开发人员发放许可证的。如果您公司的开发人员不是很多,那么在应用程序开发过程中使用 DEDE 可能是更经济的方法。


    原文链接:http://blog.csdn.net/jaminwm/article/details/4068790
    发布于 2年前, 阅读(36) | 评论(0) | 投票(0) | 收藏(0) 阅读全文...
  • 092012-03

     分析:

    metalink给出的分析和解决方案我的理解如下,如有错误请指正。
    一、目前现状是有警告信息,还未出现ora-1578错误,我们目前可以做出的选择有以下几种:
    1、解决此问题
        解决方式可以参考给出的方案a和方案b,由于此问题并非oracle RAC软件配置导致的问题,而是由裸设备配置aix导致的问题。由于裸设备配置参数都由先前管理员按照规定设定,我查阅了日志:
        CRMPODB2[/tmp]#cat oraclelv.sh

    mklv -y'cp_crs1024m' -t 'raw' oraclevg 8 hdiskpower4

    mklv -y'cp_vote1024m' -t 'raw' oraclevg 8 hdiskpower4

    mklv -y'cp_system_1024m' -t 'raw' oraclevg 10 hdiskpower4

    mklv -y'cp_pwdfile_100m' -t 'raw' oraclevg 1 hdiskpower4

    mklv -y'cp_sysaux_800m' -t 'raw' oraclevg 10 hdiskpower4

    mklv -y'cp_undo1_4096m' -t 'raw' oraclevg 40 hdiskpower4

    mklv -y'cp_undo2_4096m' -t 'raw' oraclevg 40 hdiskpower4

    mklv -y'cp_temp_4096m' -t 'raw' oraclevg 40 hdiskpower4

    mklv -y'cp_example_800m' -t 'raw' oraclevg 10 hdiskpower4

    mklv -y'cp_users_800m' -t 'raw' oraclevg 10 hdiskpower4

    确认裸设备没有加-T O参数。
    在aix和oracle9/10的某些版本中有过此问题导致的极端情况,导致ora-1578。产生重大错误。但在oracle11g中没有明确指出此问题是否已经修复。因此建议首先考虑aix调整方案采用方案a进行修正。

    方案b采用前务必先对数据库进行备份。

    方案b简单的描述是按照裸设备调整后的情况再进行重新的oracle安装和rac的实施,时间周期会导致系统至少1天不可用。

    即使方案a操作失败,依然可以使用方案b进行此问题的修复。但会花费较多的时间。


    2、忽略此问题
    首先,忽略此问题并不是放任不管。这样违背系统管理的基本要求。忽略此问题是建议对此问题进行深入的研究,依据专家意见及现场观察分析,控制此问题导致ora-1578错误的几率,达到对此风险的全面掌控,而形成系统管理的经验积累。

    问题原因是裸设备没有- T O,-T O 对于大 vg 格式卷组,-T O 选项表示逻辑卷控制块不会占用逻辑卷的首块。因此,该空间可供应用程序数据使用。应用程序可以用 IOC INFO ioctl 识别此类逻辑卷。逻辑卷具有设备子类型 DS_LVZ。不使用该选项创建的逻辑卷具有设备子类型 DS_LV。对于旧的且可伸缩的 vg 格式卷组忽略该选项。

    一般情况下,AIX的每一个逻辑卷前512字节被称为logical-volume control block (LVCB),包含了LV的一些信息。在 Oracle 9iR2 之前,为了避免和LVCB的冲突,Oracle 软件会跳过前4k字节不用。LVCB的和Oracle跳过4K的特点带来的问题:

        如果一个VG中包含多个PV,PV做了条带化(stripe),创建的LV跨在不同的PV上,这样会导致下面的问题,例如:如果stripe是 32K,db_block是8K,如果没有offset,则4个db_block就全在一个stripe里了,不会跨PV。而有了4K的offset,则肯定第四个db_block就跨stripe了,也就成了一个Oracle DB block跨在多个LUN/PV上了,如下图(例子来自于老农的文章):

         当系统崩溃的时候,很有可能造成大量的IO不完整(如果OS写了一个PV上的半block之后,来不及写下一个PV上的半个block,如果是在同一个PV则可以保证一个block同时被更新),启动Oracle的时候将会看到ORA-01578:“ORACLE data block corrupted (file # %s, block # %s)”错误,大量的corrupted block对于数据可能是致命的。

     

    AIX解决方法(来自piner)

          AIX在Oracle 9iR2以后,引进了一种新的LV类型,也就是“Z”类型LV,这种类型的LV通过lslv lv_name或者lslv -L lv_name可以看到它的类型为:DS_LV。例如:

        # lslv -L lv_test_2g_001

        DEVICESUBTYPE :DS_LVZ

          或者,Oracle的dbfsize也可以检查

        $ dbfsize /dev/rlv_test_2g_001

        Database file: /dev/rlv_test_2g_001

        Database file type: raw devicewithout 4K starting offset

        Database file size: 261248 8192 byte blocks

          如以上的结果,则显示这个LV是没有4k头部的”Z”类型的LV,如果是普通类型的lv,LV类型是DS_LV,这种类型的LV,在lslv的命令中没有任何SUBTYPE类型说明。这样的LV需要特定的VG才能支持,因为它没有LVCB了(其实LVCB的信息都保存到了VGDA中),那么,LV肯定就要靠 VGDA来管理了。

     
    采用Big VG的注意事项

          Big VG的一个bug,就是使用-T O,创建成功的DS_LVZ类型的LV,在经过chlv或者是其它lvm命令,如varyoff/varyon之后,这个标志会消失。这个情况是比较可怕的,如你采用新创建的lv创建了数据文件,但是,后来,因为HA切换或者其它原因varyoff/varyon了这个VG,甚至exportvg /importvg了这个VG,新的LV在数据库看来,不是DS_LVZ类型的LV,数据库将试图跳过4k的偏移,但是偏移其实是不存在的。具体解决方案就是,请使用scalable类型的VG或者是打以上的补丁:

    Problem is caused by defect IY94343 in AIX Operating System.

          解决方案:http://www-1.ibm.com/support/docview.wss?uid=isg1IY94343

          影响的用户:

    Users of BIG volume groups with the bos.rte.lvm fileset at the 5.3.0.53 or 5.3.0.54 level.

     
    Veritas VM的解决方法

         在AIX操作系统环境下Veritas VM 兼容AIX Logical Volume Manager (LVM), Oracle同样跳过4k。Veritas VM同样使用一种新的LV类型(devsubtype:DS_VMZ)。

    Oracle相关支持的信息:

          Oracle is enhancing both 9iR2 and 10g to recognize this new type of Volume Manager volume. A patch from Oracle will be available soon that needs to be applied to 9.2.0.5 and 10.1. The reference bug number for this Oracle patch is 3712203.

    AIX OS相关支持的信息

        This ODM patch recognizes DS_VMZ type RAW Volume Manager volumes. Without this patch, when ODM is enabled, the Oracle instance will fail with error "ORA-01251: Unknown File Header Version read".

    http://entkb.symantec.com/security/output/a269928.html

     
    AIX VG相关信息

          AIX 5.3 VG的类型包括:普通的VG,Big VG,Scalable VG。

         mkvg创建普通的VG,缺省最大32 PV/1016个PP;

         mkvg –B创建Big VG,缺省128PV/1016 PP;

         可以使用mkvg -t选择其它PP数目,对于Big VG,mkvg -t 2表示支持64PV/2032PP,具体见下图:

         通过mkvg -S可以创建Scalable-type VG。缺省1024PV/256LV/32768PP。

     

          对于普通的VG,创建的都是普通的DS_LV类型的LV

          对于Big VG,是唯一允许同时存在这两种LV类型(DS_LVZ类型没有4k头部的LV, 普通DS_LV类型的lv)的VG,如果指定-T O,则创建DS_LVZ类型的LV,否则,创建普通类型的LV,例如:#mklv -y’lv_test’ -t’raw’ -T O testvg 8 hdisk3

          对于Scalable-type VG类型的VG,创建的都是扩展的DS_LVZ类型的LV

     
    思考

    1.出问题的前提:用了AIX裸设备做datafile,且做了stripe,且LV不是DS_LVZ类型。

    2.建议使用Scalable VG(Scalable VG在5.2没有)

    3.如果Oracle软件写数据的偏移大小是oracle block大小的倍数,就不会出现上面的问题(例如:偏移4k,oracle block size 4k就没有问题;如果偏移可以设置例如8k, Oracle bock size 8k/4k,也不会有问题)

    4.另一个问题:如果一个LV跨越在多个PV上,不论是否做了stripe,就可能有类似的问题,因为PP的大小肯定也是一个整数,如128M,那么 (128M-4k)/8K还是除不尽的(来自piner的文章)。我个人认为:这个是需要考虑的问题,但是远没有stripe带来的影响大。Stripe 的情况下会出现大量的DB Block位于不同的PV, 这样系统崩溃会出现大量block corrupted。 如果仅仅是因为某个LV 跨越在多个PV上的问题,这样的影响就小多了,前提是:系统crash的时候正在写LV最后的那个block,而且仅仅一个block的损坏,对 oracle数据库还不一定是致命的。

     
    参考

    LVCB包含的一些LV信息,例如:lvid,lvname,lvname,machine id,获取LVCB信息的命令

    # getlvcb -TA datalv

             AIX LVCB

             intrapolicy = m

             copies = 1

             interpolicy = m

             lvid = 000ce0e40000d6000000010f0b787726.3

             lvname = datalv

             label = /data

             machine id = CE0E4D600

             number lps = 1600

             relocatable = y

             strict = y

             stripe width = 0

             stripe size in exponent = 0

             type = jfs2

             upperbound = 32

             fs = vfs=jfs2:log=/dev/loglv00:options=rw:account=false

             time created  = Fri Nov 24 14:17:35 2006

             time modified = Fri Nov 24 14:18:15 2006

    为了解决这个问题,AIX 推出了 Big Volume Groups 作为应对。建立 Big VG 后,创建 LV 的时候可以通过 -T O 的参数强制征用 LV 的前 4K 空间, LVCB 的信息保存在 VGDB(volume group describe area) 里面。前 4k 空间被使用的 LV 有了一个新的设备子类型(devsubtype)标记: DS_LVZ,通过 lslv 可以看到。(Oracle 也在 9.2.0.3 之后自动识别 AIX 的新 LV 类型,直接开始使用 LV 的前 4K 空间)

    对于 AIX 的可扩展性 VG,则默认创建的 LV 就会 DS_LVZ 类型,不使用 -T O 也是这样子。Big VG 可能只是一个过度类型。

    在 IBM 的系统手册中可以看到:

        The IOCINFO ioctl operation returns the devinfo structure, as defined in the /usr/include/sys/devinfo.h file

    如何知道当前裸设备创建的时候使用了 -TO ? Oracle 10g 的文档中说 $ORACLE_HOME/bin/offset 工具可以做到。Updated: offset 命令工具需要安装 RAC 组件才可用,Oracle 另外提供了一个补丁来弥补这个问题,在 Patch 3242957 中可以找到,直接解压缩,把工具提取出来即可用。 通过另一个工具可以看到相关信息:

        $ dbfsize /dev/rfoo01_pay
        Database file: /dev/rfoo01_pay
        Database file type: raw device without 4K starting offset
        Database file size: 920 8192 byte blocks

    要想得到完美的东西太难了, AIX 在 BIG VG 上仍然还有很多问题,目前已知的当属这个“MKLV -TO ON BIG VOLUME GROUPS FAILS TO PUT SOME LV INFORMATION”最为严重--得不到正确的devsubtype 类型,Oracle 则会报告读取数据文件头错误

    在oracle11g RAC选件中offset已经修复了很多此类问题。因此经过深入分析,得出结论,目前的几个警告信息最后导致ora-1578的原因有3种:
    1、外部lun的操作,对vg的移动、修改等
    2、oracle做异步写的时候会让aix日志产生错误的信息。
    3、系统掉电、意外停机等。

    在oracle11g中导致出现这种情况的可能性非常小,但不排除也有极端出现的可能。

    该系统尽量不要在外部进行vg操作,保证供电及意外停机。至于第2种情况,在oracle11gRAC环境下可以暂时忽略。做好每天的备份,以防止极端情况的出现。

    另外给出一个aix下的lvcb问题的解决方案,以供参考:
    在AIX系统中,用逻辑卷治理器(LVM)来治理存贮设备,这是他差别于传统的UNIX系统的一个重要特征,也是AIX系统的一大优势。

    大多数用户的应用系统把数据库空间直接建立在逻辑卷上,而且使用裸设备的方式存放数据,由于数据库厂商使用不了不同的方法访问裸逻辑卷设备,就出现这样一个问题:数据库程式是否覆盖逻辑卷的LVCB。

    我们都知道,逻辑卷控制块(LVCB)保存着逻辑卷的重要信息,他位于在逻辑卷开始,占用了512个字节。逻辑卷控制块包括的信息有:逻辑卷创建日期、逻辑卷的映像拷贝数和安装点(如果在逻辑卷上创建了一个JFS文件系统,才有安装点)。使用命令/usr/sbin/getlvcb能够获得逻辑卷的 LVCB。
    下面是用getlvcb命令显示逻辑卷lv1中的LVCB信息:

    #getlvcb -TA lv00
    AIX LVCB
    intrapolicy = m
    copies = 1
    interpolicy = m
    lvid = 000d287353697130.16
    lvname = lv1
    label = /allenfs
    machine id = D28734C00
    number lps = 1
    relocatable = y
    strict = y
    stripe width = 0
    stripe size in exponent = 0
    type = jfs
    upperbound = 32
    fs = log=/dev/hd8:options=rw:account=false
    time created = Fri Apr 13 17:16:35 2001
    time modified = Fri Apr 13 17:16:38 2001

    在getlvcb命令执行后,输出结果的第一行是“AIX LVCB”,这是AIX逻辑卷的标志。上面的显示的LVCB信息同样保存ODM数据库中,getlvcb命令是直接从逻辑卷上获得LVCB的内容。许多 LVM命令在运行时需要更新LVCB的内容,并且要确保LVCB的内容和LVM一致。更新LVCB之前,先读取旧的LVCB内容,分析其是否有效,如果确定其正确有效,则更新,否则就会出现问题,不能更新LVCB,同时提示如下错误信息:

    Warning, cannot write lv control block data
    用户为了能够让应用程式直接访问逻辑卷而创建了一个裸逻辑卷,大多数情况下应用程式会覆盖逻辑卷的LVCB,然而这并不是致命性的问题,用户仍然能在这个逻辑卷上执行维护命令:extendlv、mklvcopy、rmlv和crfs ?d(这个命令会损坏LVCB中的所有信息),但并不是所有的LVM命令都能成功执行,例如就无法输入(Import)一个逻辑卷,所以他需要一个正确有效的LVCB才能执行成功。

    因此通过应用程式直接访问LVCB是比较危险的,直接访问裸逻辑卷一般用于数据库系统。数据库系统使用裸设备存放数据以提高性能,例如informix的数据空间(DBSpace)能建立在一个熟设备上(例如文件系统中的一个文件),也可建立在一个裸设备上(即裸逻辑卷,有时也称为生设备),当建立在裸逻辑卷时,最佳不要让数据空间位于裸逻辑卷的开始,应该有一个偏移量(offset),偏移量的大小应大于LVCB的大小,一般用一个AIX逻辑块的大小做偏移量,即4096字节。不过有一些数据库厂商利用他们自己的方法治理逻辑卷,却覆盖了LVCB。

    如果不知道逻辑卷开始的512个字节是LVCB,数据库程式覆盖了一个完整的LVCB,就破坏了逻辑卷的LVCB,这样非常有可能损坏数据库,要解决数据库问题只能找数据库厂商,而大多数数据库系统的最新版本都避免了这种问题的发生,除非是用户在建立数据空间时没有考虑LVCB的存在。

    用上面提到的getlvcb命令能检查逻辑卷的LVCB是否被损坏,如果字符串“AIX LVCB”出现,则表明LVCB是好的,除此之外,还能用下面的命令检查逻辑卷的LVCB是否完整:

    #od -c /dev/hd1
    0000000 A I X L V C B \0 \0 j f s \0 \0 \0
    0000020 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
    0000040 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0 0 0 d 2 8
    0000060 7 3 5 3 6 9 7 1 3 0 . 1 6 \0 \0 \0
    0000100 \0 \0 \0 l v 0 0 \0 \0 \0 \0 \0 \0 \0 \0 \0
    0000120 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
    *
    0000200 \0 \0 \0 F r i A p r 1 3 1 7
    0000220 : 1 6 : 3 5 2 0 0 1 \n \0 \0 \0 \0
    0000240 \0 F r i A p r 1 3 1 7 : 1
    0000260 6 : 3 8 2 0 0 1 \n \0 \0 \0 \0 \0 D
    0000300 2 8 7 3 4 C 0 0 \0 y m m \0 y \0
    0000320 \0 001 \0 001 / a l l e n f s \0 \0 \0 \0
    0000340 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
    *
    0000520 \0 \0 \0 \0 l o g = / d e v / h d 8
    0000540 : o p t i o n s = r w : a c c o
    0000560 u n t = f a l s e \0 \0 \0 \0 \0 \0 \0
    0000600 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
    *
    … …

    当出现“AIX LVCB”字样,就说明LVCB是好的,否则就被损坏。如果逻辑卷的LVCB被损坏,而关于LVCB的内容还在ODM数据库中保存着,因此通过下面的命令能恢复逻辑卷上的LVCB:
    #echo "AIX LVCB\0" | dd of=/dev/lv1 bs=1 count=9
    #updatelv lv1 datavg (lv0是逻辑卷名,他属于datavg卷组)

    第一条命令是把逻辑卷标志写到从逻辑卷开始的9个字节中。第二命令是把ODM数据库中关于这个逻辑卷的LVCB内容写到从逻辑卷开始的512个字节中。

    如果LVCB中的fs字段内容被删掉了,还必须用chfs命令按照ODM数据库中的其他内容,更新这一项:
    # chfs -a log=/dev/hd8 /allenfs

    如果在ODM数据库中未找到关于这个逻辑卷的信息,那么这个逻辑卷可能就无救了。


    原文链接:http://blog.csdn.net/jaminwm/article/details/4205162
    发布于 2年前, 阅读(70) | 评论(0) | 投票(0) | 收藏(0) 阅读全文...
  • 092012-03

    这段时间mysql上的开发过程中崩溃2次,一直没有找到原因,由于使用macbook已经内存满配,top查看也无异常。sar也正常。mysql日志也没有什么有价值的信息。本文介绍其解决方法:修改Mac OS X下MySQL 5.0的默认连接数。

    这段时间服务器崩溃2次,一直没有找到原因,今天看到论坛发出的错误信息邮件,想起可能是MySQL的默认连接数引起的问题,一查果然,老天,默认 连接数才100, 怎么够呀,在网上找了半天资料,有说修改my.cnf的,有说修改safe_mysqld,试了,前者无用,

    后者文件找不到:)原来是以前的版本跟现在的版本有所不同。

    言归正传,我以Mac OS X 10.5.6 下面的mysql 5.0.7 手工编译版本为例说明:

    vi /usr/local/mysql/bin/mysqld_safe

    找到safe_mysqld编辑它,找到mysqld启动的那两行,在后面加上参数:

    -O max_connections=1500

    具体一点就是下面的位置:

    用红字特别说明:

      then $NOHUP_NICENESS $ledir/$MYSQLD
    $defaults --basedir=$MY_BASEDIR_VERSION
    --datadir=$DATADIR $USER_OPTION
    --pid-file=$pid_file
    --skip-external-locking
    -O max_connections=1500
    >> $err_log 2>&1 else
    eval "$NOHUP_NICENESS $ledir/$MYSQLD
    $defaults --basedir=$MY_BASEDIR_VERSION
    --datadir=$DATADIR $USER_OPTION
    --pid-file=$pid_file
    --skip-external-locking $args
    -O max_connections=1500 >>
    $err_log 2>&1"

    保存。

    # service mysqld restart
    # /usr/local/mysql/bin/mysqladmin -uroot -p variables

    输入root数据库账号的密码后可看到

    max_connections 1500 即新改动已经生效。

    还有一种方法:

    修改原代码:

    解开MySQL的原代码,进入里面的sql目录修改mysqld.cc找到下面一行:

    {"max_connections", OPT_MAX_CONNECTIONS,
    "The number of simultaneous clients allowed.", (gptr*) &max_connections,
    (gptr*) &max_connections, 0, GET_ULONG, REQUIRED_ARG, 100, 1, 16384, 0, 1,
    0},

    把它改为:

    {"max_connections", OPT_MAX_CONNECTIONS,
    "The number of simultaneous clients allowed.", (gptr*) &max_connections,
    (gptr*) &max_connections, 0, GET_ULONG, REQUIRED_ARG, 1500, 1, 16384, 0, 1,
    0},

    存盘退出,然后./configure ;make;make install可以获得同样的效果。


    原文链接:http://blog.csdn.net/jaminwm/article/details/4053714
    发布于 2年前, 阅读(22) | 评论(0) | 投票(0) | 收藏(0) 阅读全文...
  • 092012-03

    时间过了9年,我们已经成了夫妻,时间回到9年前,我们还是同学,这9年来,我们共同经历了生活、学习、工作、家庭的点点滴滴酸甜苦辣,感谢你,曼曼,陪伴我走过了这9年,我们的生活才刚开始,虽然还有许多理想没有实现,但是我知道我们在一起才是最大的理想。

     

    执子之手、与子偕老。我希望可以永远的和你在一起,你是永,我是远。


    原文链接:http://blog.csdn.net/jaminwm/article/details/4068449
    发布于 2年前, 阅读(7) | 评论(0) | 投票(0) | 收藏(0) 阅读全文...
  • 092012-03
     

    环境:

     

    macbook Mac OS X 10.5.6

    cpu:酷睿2双核2.1GHZ, DDR667 4GB

    VMware Fusion : 运行windows xp sp3

    WebSphere MQ V6.0

    DB2 Express-C V9.5.2

     

     

    Q 复制是一种新的高速技术,用来在 IBM DB2 Universal Database 管理的数据库之间移动数据。它是刚刚发布的 DB2 Information Integrator Version 8.2 中的一个亮点。Q 复制如此之快的原因之一是,它使用了强大的业务集成产品 WebSphere MQ,以压缩消息的形式在网络上缩放数据。(快意味着该产品在复制大量数据库更新时等待时间短,或者延迟时间短。)如何设置一个简单的 Q 复制场景:两个远程数据库之间的单路(one-way)或单方向(unidirectional) 复制。除此之外,您还将了解如何创建和使用 WebSphere MQ 队列管理器、消息队列,以及为复制提供传输层的通道,只需一台计算机即可,但是您需要设置 WebSphere MQ 和 Q 复制,以模拟两台远程系统之间的数据移动,这样,您就可以把教程中学到的知识应用到实际的生产环境中。与此同时,您还会在本教程的指导下,逐步掌握 Replication Center 以及其他便于进行 Q 复制的配置及管理的工具和向导的使用。
    大致步骤:
        * 如何创建并使用 WebSphere MQ 队列管理器、队列和通道。
        * 如何能够将 DB2 数据库用于复制。
        * 如何设置并操作 Q Capture 和 Q Apply 程序。
        * 如何创建复制队列映射,把源数据库和目标数据库连接起来。
        * 如何创建 Q 订阅,把源表映射到目标表。
    如果您具备 DB2 Universal Database 的基本知识(如何创建数据库,用命令或控制中心查看表的内容,以及发布一些简单的 SQL 语句)
    Microsoft Windows XP [版本 5.1.2600]
    (C) 版权所有 1985-2001 Microsoft Corp.

    C:/Documents and Settings/xujm>crtmqm SRC_QM
    WebSphere MQ 队列管理器已创建。
    创建或替换 SRC_QM 的缺省对象。
    缺省对象统计:43 个已创建。0 个已替换。0 个已失败。
    正在完成设置。
    设置完成。

    C:/Documents and Settings/xujm>crtmqm TGT_QM
    WebSphere MQ 队列管理器已创建。
    创建或替换 TGT_QM 的缺省对象。
    缺省对象统计:43 个已创建。0 个已替换。0 个已失败。
    正在完成设置。
    设置完成。

    C:/Documents and Settings/xujm>strmqm SRC_QM
    WebSphere MQ 队列管理器“SRC_QM”正在启动。
    在日志重放阶段在队列管理器“SRC_QM”上访问了 5 条日志记录。
    完成队列管理器“SRC_QM”的日志重放。
    为队列管理器“SRC_QM”恢复了事务管理器状态。
    WebSphere MQ 队列管理器‘SRC_QM’已启动。

    C:/Documents and Settings/xujm>strmqm TGT_QM
    WebSphere MQ 队列管理器“TGT_QM”正在启动。
    在日志重放阶段在队列管理器“TGT_QM”上访问了 5 条日志记录。
    完成队列管理器“TGT_QM”的日志重放。
    为队列管理器“TGT_QM”恢复了事务管理器状态。
    WebSphere MQ 队列管理器‘TGT_QM’已启动。

    C:/Documents and Settings/xujm>runmqsc
    5724-H72 (C) Copyright IBM Corp. 1994, 2005. ALL RIGHTS RESERVED.
    AMQ8146: WebSphere MQ 队列管理器不可用。

    未读取 MQSC 命令。
    所有命令均无语法错误。
    已处理所有的有效 MQSC 命令。

    C:/Documents and Settings/xujm>runmqsc SRC_QM
    5724-H72 (C) Copyright IBM Corp. 1994, 2005. ALL RIGHTS RESERVED.
    启动队列管理器 SRC_QM 的 MQSC。


    define qlocal('ADMINQ') DEFPSIST(YES)
         1 : define qlocal('ADMINQ') DEFPSIST(YES)
    AMQ8006: WebSphere MQ 队列已创建。
    define ql('RESTARTQ') defpsist(YES)
         2 : define ql('RESTARTQ') defpsist(YES)
    AMQ8006: WebSphere MQ 队列已创建。
    define QL('TGT_QM') USAGE(XMITQ) DEFPSIST(YES)
         3 : define QL('TGT_QM') USAGE(XMITQ) DEFPSIST(YES)
    AMQ8006: WebSphere MQ 队列已创建。
    define qremote('SENDQ') RNAME('RECVQ') RQMNAME('TGT_QM') XMITQ('TGT_QM') DEFPSIS
    T(YES)
         4 : define qremote('SENDQ') RNAME('RECVQ') RQMNAME('TGT_QM') XMITQ('TGT_QM'
    ) DEFPSIST(YES)
    AMQ8006: WebSphere MQ 队列已创建。

    C:/Documents and Settings/xujm>runmqsc TGT_QM
    5724-H72 (C) Copyright IBM Corp. 1994, 2005. ALL RIGHTS RESERVED.
    启动队列管理器 TGT_QM 的 MQSC。


    define ql('recvq') defpsist(yes)
         1 : define ql('recvq') defpsist(yes)
    AMQ8006: WebSphere MQ 队列已创建。
    DEFINE QLOCAL('SRC_QM') USAGE(XMITQ) DEFPSIST(YES)
         2 : DEFINE QLOCAL('SRC_QM') USAGE(XMITQ) DEFPSIST(YES)
    AMQ8006: WebSphere MQ 队列已创建。
    DEFINE QREMOTE('ADMINQ') RNAME('ADMINQ') RQMNAME('SRC_QM')XMITQ('SRC_QM') DEFPSI
    ST(YES)
         3 : DEFINE QREMOTE('ADMINQ') RNAME('ADMINQ') RQMNAME('SRC_QM')XMITQ('SRC_QM
    ') DEFPSIST(YES)
    AMQ8405: 在下面的命令段结尾或临近结尾处检测到语法错误:-
    DEFINE QREMOTE('ADMINQ') RNAME('ADMINQ') RQMNAME('SRC_QM')XMITQ

    AMQ8427: MQSC 命令的有效语法为:

      DEFINE QREMOTE(q_name)
         [ CLUSNL(namelist_name) ]               [ CLUSTER(cluster_name) ]
         [ DEFBIND( NOTFIXED | OPEN ) ]          [ DEFPRTY(integer) ]
         [ DEFPSIST( YES | NO ) ]                [ DESCR(string) ]
         [ LIKE(qremote_name) ]                  [ PUT( ENABLED | DISABLED ) ]
         [ REPLACE | NOREPLACE ]                 [ RNAME(string) ]
         [ RQMNAME(string) ]                     [ SCOPE( QMGR | CELL ) ]
         [ XMITQ(string) ]                       [ CLWLRANK(integer) ]
         [ CLWLPRTY(integer) ]
    DEFINE QREMOTE('ADMINQ') RNAME('ADMINQ') RQMNAME('SRC_QM') XMITQ('SRC_QM') DEFPS
    IST(YES)
         4 : DEFINE QREMOTE('ADMINQ') RNAME('ADMINQ') RQMNAME('SRC_QM') XMITQ('SRC_Q
    M') DEFPSIST(YES)
    AMQ8006: WebSphere MQ 队列已创建。
    DEFINE QMODEL('IBMQREP.SPILL.MODELQ') DEFSOPT(SHARED)
         5 : DEFINE QMODEL('IBMQREP.SPILL.MODELQ') DEFSOPT(SHARED)
    AMQ8006: WebSphere MQ 队列已创建。

           :
    DEFINE QMODEL('IBMQREP.SPILL.MODELQ') DEFSOPT(SHARED) MSGDLVSQ(FIFO) DEFTYPE(PER
    MDYN)
         6 : DEFINE QMODEL('IBMQREP.SPILL.MODELQ') DEFSOPT(SHARED) MSGDLVSQ(FIFO) DE
    FTYPE(PERMDYN)
    AMQ8150: WebSphere MQ 对象已存在。
    DEFINE QMODEL('IBMQREP.SPILL.MODELQ') DEFSOPT(SHARED) MSGDLVSQ(FIFO) DEFTYPE(PER
    MDYN)
         7 : DEFINE QMODEL('IBMQREP.SPILL.MODELQ') DEFSOPT(SHARED) MSGDLVSQ(FIFO) DE
    FTYPE(PERMDYN)
    AMQ8006: WebSphere MQ 队列已创建。


    C:/Documents and Settings/xujm>ipconfig

    Windows IP Configuration


    Ethernet adapter 本地连接:

            Connection-specific DNS Suffix  . : localdomain
            IP Address. . . . . . . . . . . . : 172.16.157.128
            Subnet Mask . . . . . . . . . . . : 255.255.255.0
            Default Gateway . . . . . . . . . : 172.16.157.2

    C:/Documents and Settings/xujm>runmqsc SRC_QM
    5724-H72 (C) Copyright IBM Corp. 1994, 2005. ALL RIGHTS RESERVED.
    启动队列管理器 SRC_QM 的 MQSC。


    DEFINE CHL ('SRC_QM.TO.TGT_QM') CHLTYPE(SDR) TRPTYPE(TCP) CONNAME ('172.16.157.1
    28(1450)') XMITQ('TGT_QM') DISCINT(0)
         1 : DEFINE CHL ('SRC_QM.TO.TGT_QM') CHLTYPE(SDR) TRPTYPE(TCP) CONNAME ('172
    .16.157.128(1450)') XMITQ('TGT_QM') DISCINT(0)
    AMQ8014: WebSphere MQ 通道已创建。

           :
                                                                    DEFINE CHL ('TGT
    _QM.TO.SRC_QM') CHLTYPE(RCVR) TRPTYPE(TCP)
         2 :                                                                DEFINE C
    HL ('TGT_QM.TO.SRC_QM') CHLTYPE(RCVR) TRPTYPE(TCP)
    AMQ8014: WebSphere MQ 通道已创建。

           :
    C:/Documents and Settings/xujm>runmqsc TGT_QM
    5724-H72 (C) Copyright IBM Corp. 1994, 2005. ALL RIGHTS RESERVED.
    启动队列管理器 TGT_QM 的 MQSC。


    DEFINE CHL ('TGT_QM.TO.SRC_QM') CHLTYPE(SDR) TRPTYPE(TCP) CONNAME('172.16.157.12
    8(1451)') XMITQ('SRC_QM') DISCINT(0)
         1 : DEFINE CHL ('TGT_QM.TO.SRC_QM') CHLTYPE(SDR) TRPTYPE(TCP) CONNAME('172.
    16.157.128(1451)') XMITQ('SRC_QM') DISCINT(0)
    AMQ8014: WebSphere MQ 通道已创建。
    DEFINE CHL ('SRC_QM.TO.TGT_QM') CHLTYPE(RCVR) TRPTYPE(TCP)
         2 : DEFINE CHL ('SRC_QM.TO.TGT_QM') CHLTYPE(RCVR) TRPTYPE(TCP)
    AMQ8014: WebSphere MQ 通道已创建。
    END
         3 : END
    已读取 2 个 MQSC 命令。
    所有命令均无语法错误。
    已处理所有的有效 MQSC 命令。

    C:/Documents and Settings/xujm>


    - 脚本开始 1--   DatabaseDB2LUOW (SAMPLE) [警告 *** 请不要改变此行] --

    -- CONNECT TO SAMPLE USER XXXX using XXXX;

    CREATE TABLESPACE QCASN3 MANAGED BY SYSTEM USING ('QCASN3_TSC');

    CREATE TABLE ASN.IBMQREP_CAPPARMS
    (
     QMGR VARCHAR(48) NOT NULL,
     REMOTE_SRC_SERVER VARCHAR(18),
     RESTARTQ VARCHAR(48) NOT NULL,
     ADMINQ VARCHAR(48) NOT NULL,
     STARTMODE VARCHAR(6) NOT NULL WITH DEFAULT 'WARMSI',
     MEMORY_LIMIT INTEGER NOT NULL WITH DEFAULT 500,
     COMMIT_INTERVAL INTEGER NOT NULL WITH DEFAULT 500,
     AUTOSTOP CHARACTER(1) NOT NULL WITH DEFAULT 'N',
     MONITOR_INTERVAL INTEGER NOT NULL WITH DEFAULT 60000,
     MONITOR_LIMIT INTEGER NOT NULL WITH DEFAULT 10080,
     TRACE_LIMIT INTEGER NOT NULL WITH DEFAULT 10080,
     SIGNAL_LIMIT INTEGER NOT NULL WITH DEFAULT 10080,
     PRUNE_INTERVAL INTEGER NOT NULL WITH DEFAULT 300,
     SLEEP_INTERVAL INTEGER NOT NULL WITH DEFAULT 5000,
     LOGREUSE CHARACTER(1) NOT NULL WITH DEFAULT 'N',
     LOGSTDOUT CHARACTER(1) NOT NULL WITH DEFAULT 'N',
     TERM CHARACTER(1) NOT NULL WITH DEFAULT 'Y',
     CAPTURE_PATH VARCHAR(1040) WITH DEFAULT NULL,
     ARCH_LEVEL CHARACTER(4) NOT NULL WITH DEFAULT '0905',
     COMPATIBILITY CHARACTER(4) NOT NULL WITH DEFAULT '0905',
     LOB_SEND_OPTION CHARACTER(1) NOT NULL WITH DEFAULT 'I',
     QFULL_NUM_RETRIES INTEGER NOT NULL WITH DEFAULT 30,
     QFULL_RETRY_DELAY INTEGER NOT NULL WITH DEFAULT 250
    )
     IN QCASN3;

    ALTER TABLE ASN.IBMQREP_CAPPARMS
     VOLATILE CARDINALITY;

    CREATE UNIQUE INDEX ASN.IX1CQMGRCOL ON ASN.IBMQREP_CAPPARMS
    (
     QMGR ASC
    );

    CREATE TABLE ASN.IBMQREP_SENDQUEUES
    (
     PUBQMAPNAME VARCHAR(128) NOT NULL,
     SENDQ VARCHAR(48) NOT NULL,
     RECVQ VARCHAR(48),
     MESSAGE_FORMAT CHARACTER(1) NOT NULL WITH DEFAULT 'C',
     MSG_CONTENT_TYPE CHARACTER(1) NOT NULL WITH DEFAULT 'T',
     STATE CHARACTER(1) NOT NULL WITH DEFAULT 'A',
     STATE_TIME TIMESTAMP NOT NULL WITH DEFAULT CURRENT TIMESTAMP,
     STATE_INFO CHARACTER(8),
     ERROR_ACTION CHARACTER(1) NOT NULL WITH DEFAULT 'S',
     HEARTBEAT_INTERVAL INTEGER NOT NULL WITH DEFAULT 60,
     MAX_MESSAGE_SIZE INTEGER NOT NULL WITH DEFAULT 64,
     APPLY_SERVER VARCHAR(18),
     APPLY_ALIAS VARCHAR(8),
     APPLY_SCHEMA VARCHAR(128),
     DESCRIPTION VARCHAR(254),
     MESSAGE_CODEPAGE INTEGER,
     COLUMN_DELIMITER CHARACTER(1),
     STRING_DELIMITER CHARACTER(1),
     RECORD_DELIMITER CHARACTER(1),
     DECIMAL_POINT CHARACTER(1),
     SENDRAW_IFERROR CHARACTER(1) NOT NULL WITH DEFAULT 'N',
     PRIMARY KEY(SENDQ)
    )
     IN QCASN3;

    ALTER TABLE ASN.IBMQREP_SENDQUEUES
     VOLATILE CARDINALITY;

    CREATE UNIQUE INDEX ASN.IX1PUBMAPCOL ON ASN.IBMQREP_SENDQUEUES
    (
     PUBQMAPNAME ASC
    );

    CREATE TABLE ASN.IBMQREP_SUBS
    (
     SUBNAME VARCHAR(132) NOT NULL,
     SOURCE_OWNER VARCHAR(128) NOT NULL,
     SOURCE_NAME VARCHAR(128) NOT NULL,
     TARGET_SERVER VARCHAR(18),
     TARGET_ALIAS VARCHAR(8),
     TARGET_OWNER VARCHAR(128),
     TARGET_NAME VARCHAR(128),
     TARGET_TYPE INTEGER,
     APPLY_SCHEMA VARCHAR(128),
     SENDQ VARCHAR(48) NOT NULL,
     SEARCH_CONDITION VARCHAR(2048) WITH DEFAULT NULL,
     SUB_ID INTEGER WITH DEFAULT NULL,
     SUBTYPE CHARACTER(1) NOT NULL WITH DEFAULT 'U',
     ALL_CHANGED_ROWS CHARACTER(1) NOT NULL WITH DEFAULT 'N',
     BEFORE_VALUES CHARACTER(1) NOT NULL WITH DEFAULT 'N',
     CHANGED_COLS_ONLY CHARACTER(1) NOT NULL WITH DEFAULT 'Y',
     HAS_LOADPHASE CHARACTER(1) NOT NULL WITH DEFAULT 'I',
     STATE CHARACTER(1) NOT NULL WITH DEFAULT 'N',
     STATE_TIME TIMESTAMP NOT NULL WITH DEFAULT CURRENT TIMESTAMP,
     STATE_INFO CHARACTER(8),
     STATE_TRANSITION VARCHAR(256) FOR BIT DATA,
     SUBGROUP VARCHAR(30) WITH DEFAULT NULL,
     SOURCE_NODE SMALLINT NOT NULL WITH DEFAULT 0,
     TARGET_NODE SMALLINT NOT NULL WITH DEFAULT 0,
     GROUP_MEMBERS CHARACTER(254) FOR BIT DATA WITH DEFAULT NULL,
     OPTIONS_FLAG CHARACTER(4) NOT NULL WITH DEFAULT 'NNNN',
     SUPPRESS_DELETES CHARACTER(1) NOT NULL WITH DEFAULT 'N',
     DESCRIPTION VARCHAR(200),
     TOPIC VARCHAR(256),
     PRIMARY KEY(SUBNAME),
     CONSTRAINT FKSENDQ FOREIGN KEY(SENDQ) REFERENCES
     ASN.IBMQREP_SENDQUEUES(SENDQ)
    )
     IN QCASN3;

    ALTER TABLE ASN.IBMQREP_SUBS
     VOLATILE CARDINALITY;

    CREATE TABLE ASN.IBMQREP_SRC_COLS
    (
     SUBNAME VARCHAR(132) NOT NULL,
     SRC_COLNAME VARCHAR(128) NOT NULL,
     IS_KEY SMALLINT NOT NULL WITH DEFAULT 0,
     COL_OPTIONS_FLAG CHARACTER(10) NOT NULL WITH DEFAULT 'NNNNNNNNNN',
     PRIMARY KEY(SUBNAME, SRC_COLNAME),
     CONSTRAINT FKSUBS FOREIGN KEY(SUBNAME) REFERENCES ASN.IBMQREP_SUBS
    (SUBNAME)
    )
     IN QCASN3;

    ALTER TABLE ASN.IBMQREP_SRC_COLS
     VOLATILE CARDINALITY;

    CREATE TABLE ASN.IBMQREP_SRCH_COND
    (
     ASNQREQD INTEGER
    )
     IN QCASN3;

    CREATE TABLE ASN.IBMQREP_SIGNAL
    (
     SIGNAL_TIME TIMESTAMP NOT NULL WITH DEFAULT CURRENT TIMESTAMP,
     SIGNAL_TYPE VARCHAR(30) NOT NULL,
     SIGNAL_SUBTYPE VARCHAR(30),
     SIGNAL_INPUT_IN VARCHAR(500),
     SIGNAL_STATE CHARACTER(1) NOT NULL WITH DEFAULT 'P',
     SIGNAL_LSN CHARACTER(10) FOR BIT DATA
    )
     DATA CAPTURE CHANGES
     IN QCASN3;

    ALTER TABLE ASN.IBMQREP_SIGNAL
     VOLATILE CARDINALITY;

    CREATE TABLE ASN.IBMQREP_CAPTRACE
    (
     OPERATION CHARACTER(8) NOT NULL,
     TRACE_TIME TIMESTAMP NOT NULL,
     DESCRIPTION VARCHAR(1024) NOT NULL,
     REASON_CODE INTEGER,
     MQ_CODE INTEGER
    )
     IN QCASN3;

    CREATE TABLE ASN.IBMQREP_CAPMON
    (
     MONITOR_TIME TIMESTAMP NOT NULL,
     CURRENT_LOG_TIME TIMESTAMP NOT NULL,
     CAPTURE_IDLE INTEGER NOT NULL,
     CURRENT_MEMORY INTEGER NOT NULL,
     ROWS_PROCESSED INTEGER NOT NULL,
     TRANS_SKIPPED INTEGER NOT NULL,
     TRANS_PROCESSED INTEGER NOT NULL,
     TRANS_SPILLED INTEGER NOT NULL,
     MAX_TRANS_SIZE INTEGER NOT NULL,
     QUEUES_IN_ERROR INTEGER NOT NULL,
     RESTART_SEQ CHARACTER(10) FOR BIT DATA NOT NULL,
     CURRENT_SEQ CHARACTER(10) FOR BIT DATA NOT NULL,
     LAST_EOL_TIME TIMESTAMP,
     PRIMARY KEY(MONITOR_TIME)
    )
     IN QCASN3;

    ALTER TABLE ASN.IBMQREP_CAPMON
     VOLATILE CARDINALITY;

    CREATE TABLE ASN.IBMQREP_CAPQMON
    (
     MONITOR_TIME TIMESTAMP NOT NULL,
     SENDQ VARCHAR(48) NOT NULL,
     ROWS_PUBLISHED INTEGER NOT NULL,
     TRANS_PUBLISHED INTEGER NOT NULL,
     CHG_ROWS_SKIPPED INTEGER NOT NULL,
     DELROWS_SUPPRESSED INTEGER NOT NULL,
     ROWS_SKIPPED INTEGER NOT NULL,
     QFULL_ERROR_COUNT INTEGER NOT NULL,
     LOBS_TOO_BIG INTEGER NOT NULL WITH DEFAULT 0,
     XMLDOCS_TOO_BIG INTEGER NOT NULL WITH DEFAULT 0,
     PRIMARY KEY(MONITOR_TIME, SENDQ)
    )
     IN QCASN3;

    ALTER TABLE ASN.IBMQREP_CAPQMON
     VOLATILE CARDINALITY;

    CREATE TABLE ASN.IBMQREP_CAPENQ
    (
     LOCKNAME INTEGER
    )
     IN QCASN3;

    CREATE TABLE ASN.IBMQREP_ADMINMSG
    (
     MQMSGID CHARACTER(24) FOR BIT DATA NOT NULL,
     MSG_TIME TIMESTAMP NOT NULL WITH DEFAULT CURRENT TIMESTAMP,
     PRIMARY KEY(MQMSGID)
    )
     IN QCASN3;

    ALTER TABLE ASN.IBMQREP_ADMINMSG
     VOLATILE CARDINALITY;

    CREATE TABLE ASN.IBMQREP_IGNTRAN
    (
     AUTHID CHARACTER(128),
     AUTHTOKEN CHARACTER(30),
     PLANNAME CHARACTER(8),
     IGNTRANTRC CHARACTER(1) NOT NULL WITH DEFAULT 'Y'
    )
     IN QCASN3;

    CREATE TABLE ASN.IBMQREP_IGNTRANTRC
    (
     IGNTRAN_TIME TIMESTAMP NOT NULL WITH DEFAULT CURRENT TIMESTAMP,
     AUTHID CHARACTER(128),
     AUTHTOKEN CHARACTER(30),
     PLANNAME CHARACTER(8),
     TRANSID CHARACTER(10) FOR BIT DATA NOT NULL,
     COMMITLSN CHARACTER(10) FOR BIT DATA NOT NULL
    )
     IN QCASN3;

    CREATE TABLE ASN.IBMQREP_CAPENVINFO
    (
     NAME VARCHAR(30) NOT NULL,
     VALUE VARCHAR(3800)
    )
     IN QCASN3;

    INSERT INTO ASN.IBMQREP_CAPPARMS
     (qmgr, restartq, adminq, startmode, memory_limit, commit_interval,
     autostop, monitor_interval, monitor_limit, trace_limit, signal_limit,
     prune_interval, sleep_interval, logreuse, logstdout, term, arch_level
    , compatibility)
     VALUES
     ('SRC_QM', 'RESTARTQ', 'ADMINQ', 'WARMSI', 500, 500, 'N', 60000,
     10080, 10080, 10080, 300, 5000, 'N', 'N', 'Y', '0905', '0905');

    -- COMMIT;

    -- 脚本开始 1--   DatabaseDB2LUOW (TARGET) [警告 *** 请不要改变此行] --

    -- CONNECT TO TARGET USER XXXX using XXXX;

    CREATE TABLESPACE QAASN2 MANAGED BY SYSTEM USING ('QAASN2_TSC');

    CREATE TABLE ASN.IBMQREP_APPLYPARMS
    (
     QMGR VARCHAR(48) NOT NULL,
     MONITOR_LIMIT INTEGER NOT NULL WITH DEFAULT 10080,
     TRACE_LIMIT INTEGER NOT NULL WITH DEFAULT 10080,
     MONITOR_INTERVAL INTEGER NOT NULL WITH DEFAULT 60000,
     PRUNE_INTERVAL INTEGER NOT NULL WITH DEFAULT 300,
     AUTOSTOP CHARACTER(1) NOT NULL WITH DEFAULT 'N',
     LOGREUSE CHARACTER(1) NOT NULL WITH DEFAULT 'N',
     LOGSTDOUT CHARACTER(1) NOT NULL WITH DEFAULT 'N',
     APPLY_PATH VARCHAR(1040) WITH DEFAULT NULL,
     ARCH_LEVEL CHARACTER(4) NOT NULL WITH DEFAULT '0905',
     TERM CHARACTER(1) NOT NULL WITH DEFAULT 'Y',
     PWDFILE VARCHAR(48) WITH DEFAULT NULL,
     DEADLOCK_RETRIES INTEGER NOT NULL WITH DEFAULT 3,
     SQL_CAP_SCHEMA VARCHAR(128) WITH DEFAULT NULL
    )
     IN QAASN2;

    ALTER TABLE ASN.IBMQREP_APPLYPARMS
     VOLATILE CARDINALITY;

    CREATE UNIQUE INDEX ASN.IX1AQMGRCOL ON ASN.IBMQREP_APPLYPARMS
    (
     QMGR ASC
    );

    CREATE TABLE ASN.IBMQREP_RECVQUEUES
    (
     REPQMAPNAME VARCHAR(128) NOT NULL,
     RECVQ VARCHAR(48) NOT NULL,
     SENDQ VARCHAR(48) WITH DEFAULT NULL,
     ADMINQ VARCHAR(48) NOT NULL,
     NUM_APPLY_AGENTS INTEGER NOT NULL WITH DEFAULT 16,
     MEMORY_LIMIT INTEGER NOT NULL WITH DEFAULT 64,
     CAPTURE_SERVER VARCHAR(18) NOT NULL,
     CAPTURE_ALIAS VARCHAR(8) NOT NULL,
     CAPTURE_SCHEMA VARCHAR(128) NOT NULL WITH DEFAULT 'ASN',
     STATE CHARACTER(1) NOT NULL WITH DEFAULT 'A',
     STATE_TIME TIMESTAMP NOT NULL WITH DEFAULT CURRENT TIMESTAMP,
     STATE_INFO CHARACTER(8),
     DESCRIPTION VARCHAR(254),
     SOURCE_TYPE CHARACTER(1) WITH DEFAULT ' ',
     MAXAGENTS_CORRELID INTEGER WITH DEFAULT NULL,
     PRIMARY KEY(RECVQ)
    )
     IN QAASN2;

    ALTER TABLE ASN.IBMQREP_RECVQUEUES
     VOLATILE CARDINALITY;

    CREATE UNIQUE INDEX ASN.IX1REPMAPCOL ON ASN.IBMQREP_RECVQUEUES
    (
     REPQMAPNAME ASC
    );

    CREATE TABLE ASN.IBMQREP_TARGETS
    (
     SUBNAME VARCHAR(132) NOT NULL,
     RECVQ VARCHAR(48) NOT NULL,
     SUB_ID INTEGER WITH DEFAULT NULL,
     SOURCE_SERVER VARCHAR(18) NOT NULL,
     SOURCE_ALIAS VARCHAR(8) NOT NULL,
     SOURCE_OWNER VARCHAR(128) NOT NULL,
     SOURCE_NAME VARCHAR(128) NOT NULL,
     SRC_NICKNAME_OWNER VARCHAR(128),
     SRC_NICKNAME VARCHAR(128),
     TARGET_OWNER VARCHAR(128) NOT NULL,
     TARGET_NAME VARCHAR(128) NOT NULL,
     TARGET_TYPE INTEGER NOT NULL WITH DEFAULT 1,
     FEDERATED_TGT_SRVR VARCHAR(18) WITH DEFAULT NULL,
     STATE CHARACTER(1) NOT NULL WITH DEFAULT 'I',
     STATE_TIME TIMESTAMP NOT NULL WITH DEFAULT CURRENT TIMESTAMP,
     STATE_INFO CHARACTER(8),
     SUBTYPE CHARACTER(1) NOT NULL WITH DEFAULT 'U',
     CONFLICT_RULE CHARACTER(1) NOT NULL WITH DEFAULT 'K',
     CONFLICT_ACTION CHARACTER(1) NOT NULL WITH DEFAULT 'I',
     ERROR_ACTION CHARACTER(1) NOT NULL WITH DEFAULT 'Q',
     SPILLQ VARCHAR(48) WITH DEFAULT NULL,
     OKSQLSTATES VARCHAR(128) WITH DEFAULT NULL,
     SUBGROUP VARCHAR(30) WITH DEFAULT NULL,
     SOURCE_NODE SMALLINT NOT NULL WITH DEFAULT 0,
     TARGET_NODE SMALLINT NOT NULL WITH DEFAULT 0,
     GROUP_INIT_ROLE CHARACTER(1) WITH DEFAULT NULL,
     HAS_LOADPHASE CHARACTER(1) NOT NULL WITH DEFAULT 'N',
     LOAD_TYPE SMALLINT NOT NULL WITH DEFAULT 0,
     DESCRIPTION VARCHAR(254),
     SEARCH_CONDITION VARCHAR(2048) WITH DEFAULT NULL,
     MODELQ VARCHAR(36) NOT NULL WITH DEFAULT 'IBMQREP.SPILL.MODELQ',
     CCD_CONDENSED CHARACTER(1) WITH DEFAULT 'Y',
     CCD_COMPLETE CHARACTER(1) WITH DEFAULT 'Y',
     SOURCE_TYPE CHARACTER(1) WITH DEFAULT ' '
    )
     IN QAASN2;

    ALTER TABLE ASN.IBMQREP_TARGETS
     VOLATILE CARDINALITY;

    CREATE UNIQUE INDEX ASN.IX1TARGETS ON ASN.IBMQREP_TARGETS
    (
     SUBNAME ASC,
     RECVQ ASC
    );

    CREATE INDEX ASN.IX2TARGETS ON ASN.IBMQREP_TARGETS
    (
     TARGET_OWNER ASC,
     TARGET_NAME ASC,
     RECVQ ASC,
     SOURCE_OWNER ASC,
     SOURCE_NAME ASC
    );

    CREATE INDEX ASN.IX3TARGETS ON ASN.IBMQREP_TARGETS
    (
     RECVQ ASC,
     SUB_ID ASC
    );

    CREATE TABLE ASN.IBMQREP_TRG_COLS
    (
     RECVQ VARCHAR(48) NOT NULL,
     SUBNAME VARCHAR(132) NOT NULL,
     SOURCE_COLNAME VARCHAR(254) NOT NULL,
     TARGET_COLNAME VARCHAR(128) NOT NULL,
     TARGET_COLNO INTEGER WITH DEFAULT NULL,
     MSG_COL_CODEPAGE INTEGER WITH DEFAULT NULL,
     MSG_COL_NUMBER SMALLINT WITH DEFAULT NULL,
     MSG_COL_TYPE SMALLINT WITH DEFAULT NULL,
     MSG_COL_LENGTH INTEGER WITH DEFAULT NULL,
     IS_KEY CHARACTER(1) NOT NULL,
     MAPPING_TYPE CHARACTER(1) WITH DEFAULT NULL,
     SRC_COL_MAP VARCHAR(2000) WITH DEFAULT NULL,
     BEF_TARG_COLNAME VARCHAR(128) WITH DEFAULT NULL
    )
     IN QAASN2;

    ALTER TABLE ASN.IBMQREP_TRG_COLS
     VOLATILE CARDINALITY;

    CREATE UNIQUE INDEX ASN.IX1TRGCOL ON ASN.IBMQREP_TRG_COLS
    (
     RECVQ ASC,
     SUBNAME ASC,
     TARGET_COLNAME ASC
    );

    CREATE TABLE ASN.IBMQREP_SPILLQS
    (
     SPILLQ VARCHAR(48) NOT NULL,
     SUBNAME VARCHAR(132) NOT NULL,
     RECVQ VARCHAR(48) NOT NULL,
     PRIMARY KEY(SPILLQ)
    )
     IN QAASN2;

    ALTER TABLE ASN.IBMQREP_SPILLQS
     VOLATILE CARDINALITY;

    CREATE TABLE ASN.IBMQREP_EXCEPTIONS
    (
     EXCEPTION_TIME TIMESTAMP NOT NULL WITH DEFAULT CURRENT TIMESTAMP,
     RECVQ VARCHAR(48) NOT NULL,
     SRC_COMMIT_LSN VARCHAR(48) FOR BIT DATA NOT NULL,
     SRC_TRANS_TIME TIMESTAMP NOT NULL,
     SUBNAME VARCHAR(132) NOT NULL,
     REASON CHARACTER(12) NOT NULL,
     SQLCODE INTEGER,
     SQLSTATE CHARACTER(5),
     SQLERRMC VARCHAR(70) FOR BIT DATA,
     OPERATION VARCHAR(18) NOT NULL,
     TEXT CLOB(32768) NOT LOGGED NOT COMPACT NOT NULL,
     IS_APPLIED CHARACTER(1) NOT NULL,
     CONFLICT_RULE CHARACTER(1)
    )
     IN QAASN2;

    CREATE TABLE ASN.IBMQREP_APPLYTRACE
    (
     OPERATION CHARACTER(8) NOT NULL,
     TRACE_TIME TIMESTAMP NOT NULL,
     DESCRIPTION VARCHAR(1024) NOT NULL,
     REASON_CODE INTEGER,
     MQ_CODE INTEGER
    )
     IN QAASN2;

    ALTER TABLE ASN.IBMQREP_APPLYTRACE
     VOLATILE CARDINALITY;

    CREATE INDEX ASN.IX1TRCTMCOL ON ASN.IBMQREP_APPLYTRACE
    (
     TRACE_TIME ASC
    );

    CREATE TABLE ASN.IBMQREP_APPLYMON
    (
     MONITOR_TIME TIMESTAMP NOT NULL,
     RECVQ VARCHAR(48) NOT NULL,
     QSTART_TIME TIMESTAMP NOT NULL,
     CURRENT_MEMORY INTEGER NOT NULL,
     QDEPTH INTEGER NOT NULL,
     END2END_LATENCY INTEGER NOT NULL,
     QLATENCY INTEGER NOT NULL,
     APPLY_LATENCY INTEGER NOT NULL,
     TRANS_APPLIED INTEGER NOT NULL,
     ROWS_APPLIED INTEGER NOT NULL,
     TRANS_SERIALIZED INTEGER NOT NULL,
     RI_DEPENDENCIES INTEGER NOT NULL,
     RI_RETRIES INTEGER NOT NULL,
     DEADLOCK_RETRIES INTEGER NOT NULL,
     ROWS_NOT_APPLIED INTEGER NOT NULL,
     MONSTER_TRANS INTEGER NOT NULL,
     MEM_FULL_TIME INTEGER NOT NULL,
     APPLY_SLEEP_TIME INTEGER NOT NULL,
     SPILLED_ROWS INTEGER NOT NULL,
     SPILLEDROWSAPPLIED INTEGER NOT NULL,
     OLDEST_TRANS TIMESTAMP NOT NULL,
     OKSQLSTATE_ERRORS INTEGER NOT NULL,
     HEARTBEAT_LATENCY INTEGER NOT NULL,
     KEY_DEPENDENCIES INTEGER NOT NULL,
     UNIQ_DEPENDENCIES INTEGER NOT NULL,
     UNIQ_RETRIES INTEGER NOT NULL,
     OLDEST_INFLT_TRANS TIMESTAMP,
     JOB_DEPENDENCIES INTEGER,
     CAPTURE_LATENCY INTEGER,
     PRIMARY KEY(MONITOR_TIME, RECVQ)
    )
     IN QAASN2;

    ALTER TABLE ASN.IBMQREP_APPLYMON
     VOLATILE CARDINALITY;

    CREATE TABLE ASN.IBMQREP_DONEMSG
    (
     RECVQ VARCHAR(48) NOT NULL,
     MQMSGID CHARACTER(24) FOR BIT DATA NOT NULL,
     PRIMARY KEY(RECVQ, MQMSGID)
    )
     IN QAASN2;

    ALTER TABLE ASN.IBMQREP_DONEMSG
     VOLATILE CARDINALITY
     APPEND ON;

    CREATE TABLE ASN.IBMQREP_SPILLEDROW
    (
     SPILLQ VARCHAR(48) NOT NULL,
     MQMSGID CHARACTER(24) FOR BIT DATA NOT NULL,
     PRIMARY KEY(SPILLQ, MQMSGID)
    )
     IN QAASN2;

    ALTER TABLE ASN.IBMQREP_SPILLEDROW
     VOLATILE CARDINALITY;

    CREATE TABLE ASN.IBMQREP_SAVERI
    (
     SUBNAME VARCHAR(132) NOT NULL,
     RECVQ VARCHAR(48) NOT NULL,
     CONSTNAME VARCHAR(128) NOT NULL,
     TABSCHEMA VARCHAR(128) NOT NULL,
     TABNAME VARCHAR(128) NOT NULL,
     REFTABSCHEMA VARCHAR(128) NOT NULL,
     REFTABNAME VARCHAR(128) NOT NULL,
     ALTER_RI_DDL VARCHAR(1680) NOT NULL,
     TYPE_OF_LOAD CHARACTER(1) NOT NULL,
     DELETERULE CHARACTER(1),
     UPDATERULE CHARACTER(1)
    )
     IN QAASN2;

    ALTER TABLE ASN.IBMQREP_SAVERI
     VOLATILE CARDINALITY;

    CREATE TABLE ASN.IBMQREP_APPLYENQ
    (
     LOCKNAME INTEGER
    )
     IN QAASN2;

    CREATE TABLE ASN.IBMQREP_APPENVINFO
    (
     NAME VARCHAR(30) NOT NULL,
     VALUE VARCHAR(3800)
    )
     IN QAASN2;

    INSERT INTO ASN.IBMQREP_APPLYPARMS
     (qmgr, monitor_limit, trace_limit, monitor_interval, prune_interval,
     autostop, logreuse, logstdout, arch_level, term, deadlock_retries)
     VALUES
     ('TGT_QM', 10080, 10080, 60000, 300, 'N', 'N', 'N', '0905', 'Y', 3);

    -- COMMIT;


    - 脚本开始 1--   DatabaseDB2LUOW (SAMPLE) [警告 *** 请不要改变此行] --

    -- CONNECT TO SAMPLE USER XXXX using XXXX;

    INSERT INTO ASN.IBMQREP_SENDQUEUES
     (pubqmapname, sendq, message_format, msg_content_type, state,
     error_action, heartbeat_interval, max_message_size, description,
     apply_alias, apply_schema, recvq, apply_server, sendraw_iferror)
     VALUES
     ('EMPLOYEE_QMAP', 'SENDQ', 'C', 'T', 'A', 'S', 60, 64, '', 'TARGET',
     'ASN', 'recvq', 'TARGET', 'N');

    -- COMMIT;

    -- 脚本开始 2--   DatabaseDB2LUOW (TARGET) [警告 *** 请不要改变此行] --

    -- CONNECT TO TARGET USER XXXX using XXXX;

    INSERT INTO ASN.IBMQREP_RECVQUEUES
     (repqmapname, recvq, sendq, adminq, capture_alias, capture_schema,
     num_apply_agents, memory_limit, state, description, capture_server,
     source_type, maxagents_correlid)
     VALUES
     ('EMPLOYEE_QMAP', 'recvq', 'SENDQ', 'ADMINQ', 'SAMPLE', 'ASN', 16, 2
    , 'A', '', 'SAMPLE', 'D', 0);

    -- COMMIT;


    -- 脚本开始 1--   DatabaseDB2LUOW (SAMPLE) [警告 *** 请不要改变此行] --

    -- CONNECT TO SAMPLE USER XXXX using XXXX;

    ALTER TABLE XUJM.EMPLOYEE
     DATA CAPTURE CHANGES INCLUDE LONGVAR COLUMNS;

    INSERT INTO ASN.IBMQREP_SUBS
     (subname, source_owner, source_name, sendq, subtype,
     all_changed_rows, before_values, changed_cols_only, has_loadphase,
     state, source_node, target_node, options_flag, suppress_deletes,
     target_server, target_alias, target_owner, target_name, target_type,
     apply_schema)
     VALUES
     ('EMPLOYEE0001', 'XUJM', 'EMPLOYEE', 'SENDQ', 'U', 'N', 'N', 'Y',
     'I', 'N', 0, 0, 'NNNN', 'N', 'TARGET', 'TARGET', 'XUJM',
     'TGT_EMPLOYEE', 1, 'ASN');

    INSERT INTO ASN.IBMQREP_SRC_COLS
     (subname, src_colname, is_key, col_options_flag)
     VALUES
     ('EMPLOYEE0001', 'EMPNO', 1, 'YNNNNNNNNN');

    INSERT INTO ASN.IBMQREP_SRC_COLS
     (subname, src_colname, is_key, col_options_flag)
     VALUES
     ('EMPLOYEE0001', 'FIRSTNME', 0, 'NNNNNNNNNN');

    INSERT INTO ASN.IBMQREP_SRC_COLS
     (subname, src_colname, is_key, col_options_flag)
     VALUES
     ('EMPLOYEE0001', 'MIDINIT', 0, 'NNNNNNNNNN');

    INSERT INTO ASN.IBMQREP_SRC_COLS
     (subname, src_colname, is_key, col_options_flag)
     VALUES
     ('EMPLOYEE0001', 'LASTNAME', 0, 'NNNNNNNNNN');

    INSERT INTO ASN.IBMQREP_SRC_COLS
     (subname, src_colname, is_key, col_options_flag)
     VALUES
     ('EMPLOYEE0001', 'WORKDEPT', 0, 'NNNNNNNNNN');

    INSERT INTO ASN.IBMQREP_SRC_COLS
     (subname, src_colname, is_key, col_options_flag)
     VALUES
     ('EMPLOYEE0001', 'PHONENO', 0, 'NNNNNNNNNN');

    INSERT INTO ASN.IBMQREP_SRC_COLS
     (subname, src_colname, is_key, col_options_flag)
     VALUES
     ('EMPLOYEE0001', 'HIREDATE', 0, 'NNNNNNNNNN');

    INSERT INTO ASN.IBMQREP_SRC_COLS
     (subname, src_colname, is_key, col_options_flag)
     VALUES
     ('EMPLOYEE0001', 'JOB', 0, 'NNNNNNNNNN');

    INSERT INTO ASN.IBMQREP_SRC_COLS
     (subname, src_colname, is_key, col_options_flag)
     VALUES
     ('EMPLOYEE0001', 'EDLEVEL', 0, 'NNNNNNNNNN');

    INSERT INTO ASN.IBMQREP_SRC_COLS
     (subname, src_colname, is_key, col_options_flag)
     VALUES
     ('EMPLOYEE0001', 'SEX', 0, 'NNNNNNNNNN');

    INSERT INTO ASN.IBMQREP_SRC_COLS
     (subname, src_colname, is_key, col_options_flag)
     VALUES
     ('EMPLOYEE0001', 'BIRTHDATE', 0, 'NNNNNNNNNN');

    INSERT INTO ASN.IBMQREP_SRC_COLS
     (subname, src_colname, is_key, col_options_flag)
     VALUES
     ('EMPLOYEE0001', 'SALARY', 0, 'NNNNNNNNNN');

    INSERT INTO ASN.IBMQREP_SRC_COLS
     (subname, src_colname, is_key, col_options_flag)
     VALUES
     ('EMPLOYEE0001', 'BONUS', 0, 'NNNNNNNNNN');

    INSERT INTO ASN.IBMQREP_SRC_COLS
     (subname, src_colname, is_key, col_options_flag)
     VALUES
     ('EMPLOYEE0001', 'COMM', 0, 'NNNNNNNNNN');

    -- COMMIT;

    -- 脚本开始 2--   DatabaseDB2LUOW (TARGET) [警告 *** 请不要改变此行] --

    -- CONNECT TO TARGET USER XXXX using XXXX;

    CREATE TABLESPACE TSEMPLOYEE MANAGED BY DATABASE USING (FILE
     'EMPLOYEE' 32768 K);

    CREATE TABLE XUJM.TGT_EMPLOYEE
    (
     EMPNO CHARACTER(6) NOT NULL,
     FIRSTNME VARCHAR(12) NOT NULL,
     MIDINIT CHARACTER(1),
     LASTNAME VARCHAR(15) NOT NULL,
     WORKDEPT CHARACTER(3),
     PHONENO CHARACTER(4),
     HIREDATE DATE,
     JOB CHARACTER(8),
     EDLEVEL SMALLINT NOT NULL,
     SEX CHARACTER(1),
     BIRTHDATE DATE,
     SALARY DECIMAL(9,2),
     BONUS DECIMAL(9,2),
     COMM DECIMAL(9,2)
    )
     IN TSEMPLOYEE;

    CREATE UNIQUE INDEX XUJM.IXEMPLOYEE ON XUJM.TGT_EMPLOYEE
    (
     EMPNO ASC
    );

    INSERT INTO ASN.IBMQREP_TARGETS
     (subname, recvq, source_owner, source_name, target_owner,
     target_name, modelq, source_server, source_alias, target_type, state,
     subtype, conflict_rule, conflict_action, error_action, source_node,
     target_node, load_type, has_loadphase, source_type)
     VALUES
     ('EMPLOYEE0001', 'recvq', 'XUJM', 'EMPLOYEE', 'XUJM', 'TGT_EMPLOYEE'
    , 'IBMQREP.SPILL.MODELQ', 'SAMPLE', 'SAMPLE', 1, 'I', 'U', 'K', 'I',
     'Q', 0, 0, 0, 'I', 'D');

    INSERT INTO ASN.IBMQREP_TRG_COLS
     (subname, recvq, target_colname, source_colname, is_key,
     target_colNo, mapping_type, src_col_map, bef_targ_colname)
     VALUES
     ('EMPLOYEE0001', 'recvq', 'EMPNO', 'EMPNO', 'Y', 0, 'R', null, null);

    INSERT INTO ASN.IBMQREP_TRG_COLS
     (subname, recvq, target_colname, source_colname, is_key,
     target_colNo, mapping_type, src_col_map, bef_targ_colname)
     VALUES
     ('EMPLOYEE0001', 'recvq', 'FIRSTNME', 'FIRSTNME', 'N', 1, 'R', null,
     null);

    INSERT INTO ASN.IBMQREP_TRG_COLS
     (subname, recvq, target_colname, source_colname, is_key,
     target_colNo, mapping_type, src_col_map, bef_targ_colname)
     VALUES
     ('EMPLOYEE0001', 'recvq', 'MIDINIT', 'MIDINIT', 'N', 2, 'R', null,
     null);

    INSERT INTO ASN.IBMQREP_TRG_COLS
     (subname, recvq, target_colname, source_colname, is_key,
     target_colNo, mapping_type, src_col_map, bef_targ_colname)
     VALUES
     ('EMPLOYEE0001', 'recvq', 'LASTNAME', 'LASTNAME', 'N', 3, 'R', null,
     null);

    INSERT INTO ASN.IBMQREP_TRG_COLS
     (subname, recvq, target_colname, source_colname, is_key,
     target_colNo, mapping_type, src_col_map, bef_targ_colname)
     VALUES
     ('EMPLOYEE0001', 'recvq', 'WORKDEPT', 'WORKDEPT', 'N', 4, 'R', null,
     null);

    INSERT INTO ASN.IBMQREP_TRG_COLS
     (subname, recvq, target_colname, source_colname, is_key,
     target_colNo, mapping_type, src_col_map, bef_targ_colname)
     VALUES
     ('EMPLOYEE0001', 'recvq', 'PHONENO', 'PHONENO', 'N', 5, 'R', null,
     null);

    INSERT INTO ASN.IBMQREP_TRG_COLS
     (subname, recvq, target_colname, source_colname, is_key,
     target_colNo, mapping_type, src_col_map, bef_targ_colname)
     VALUES
     ('EMPLOYEE0001', 'recvq', 'HIREDATE', 'HIREDATE', 'N', 6, 'R', null,
     null);

    INSERT INTO ASN.IBMQREP_TRG_COLS
     (subname, recvq, target_colname, source_colname, is_key,
     target_colNo, mapping_type, src_col_map, bef_targ_colname)
     VALUES
     ('EMPLOYEE0001', 'recvq', 'JOB', 'JOB', 'N', 7, 'R', null, null);

    INSERT INTO ASN.IBMQREP_TRG_COLS
     (subname, recvq, target_colname, source_colname, is_key,
     target_colNo, mapping_type, src_col_map, bef_targ_colname)
     VALUES
     ('EMPLOYEE0001', 'recvq', 'EDLEVEL', 'EDLEVEL', 'N', 8, 'R', null,
     null);

    INSERT INTO ASN.IBMQREP_TRG_COLS
     (subname, recvq, target_colname, source_colname, is_key,
     target_colNo, mapping_type, src_col_map, bef_targ_colname)
     VALUES
     ('EMPLOYEE0001', 'recvq', 'SEX', 'SEX', 'N', 9, 'R', null, null);

    INSERT INTO ASN.IBMQREP_TRG_COLS
     (subname, recvq, target_colname, source_colname, is_key,
     target_colNo, mapping_type, src_col_map, bef_targ_colname)
     VALUES
     ('EMPLOYEE0001', 'recvq', 'BIRTHDATE', 'BIRTHDATE', 'N', 10, 'R',
     null, null);

    INSERT INTO ASN.IBMQREP_TRG_COLS
     (subname, recvq, target_colname, source_colname, is_key,
     target_colNo, mapping_type, src_col_map, bef_targ_colname)
     VALUES
     ('EMPLOYEE0001', 'recvq', 'SALARY', 'SALARY', 'N', 11, 'R', null,
     null);

    INSERT INTO ASN.IBMQREP_TRG_COLS
     (subname, recvq, target_colname, source_colname, is_key,
     target_colNo, mapping_type, src_col_map, bef_targ_colname)
     VALUES
     ('EMPLOYEE0001', 'recvq', 'BONUS', 'BONUS', 'N', 12, 'R', null, null
    );

    INSERT INTO ASN.IBMQREP_TRG_COLS
     (subname, recvq, target_colname, source_colname, is_key,
     target_colNo, mapping_type, src_col_map, bef_targ_colname)
     VALUES
     ('EMPLOYEE0001', 'recvq', 'COMM', 'COMM', 'N', 13, 'R', null, null);

    -- COMMIT;


    C:/>strmqm SRC_QM
    WebSphere MQ 队列管理器正在运行。

    C:/>strmqm TGT_QM
    WebSphere MQ 队列管理器正在运行。

    C:/>runmqlsr -t tcp -m SRC_QM -p 1451
    5724-H72 (C) Copyright IBM Corp. 1994, 2005. ALL RIGHTS RESERVED.

    在 Windows 上,您还可以用 start runmqlsr 为监听器打开新的命令窗口,这样您就可以继续使用当前的命令窗口。在 Linux 和 UNIX 上,在命令的末尾加上空格和( &)符号,也可以达到同样的效果。

    Microsoft Windows XP [版本 5.1.2600]
    (C) 版权所有 1985-2001 Microsoft Corp.

    C:/Documents and Settings/xujm>runmqsc SRC_QM
    5724-H72 (C) Copyright IBM Corp. 1994, 2005. ALL RIGHTS RESERVED.
    启动队列管理器 SRC_QM 的 MQSC。


    start channel (SRC_QM.TO.TGT_QM)
         1 : start channel (SRC_QM.TO.TGT_QM)
    AMQ8018: 启动 WebSphere MQ 通道已接受。
    end
         2 : end
    读取一个 MQSC 命令。
    所有命令均无语法错误。
    已处理所有的有效 MQSC 命令。

    C:/Documents and Settings/xujm>runmqlsr -t tcp -m TGT_QM -P 1450
    5724-H72 (C) Copyright IBM Corp. 1994, 2005. ALL RIGHTS RESERVED.

    C:/Documents and Settings/xujm>runmqsc TGT_QM
    5724-H72 (C) Copyright IBM Corp. 1994, 2005. ALL RIGHTS RESERVED.
    启动队列管理器 TGT_QM 的 MQSC。


    start channel (TGT_QM.TO.SRC_QM)
         1 : start channel (TGT_QM.TO.SRC_QM)
    AMQ8018: 启动 WebSphere MQ 通道已接受。
    END
         2 : END
    读取一个 MQSC 命令。
    所有命令均无语法错误。
    已处理所有的有效 MQSC 命令。

    C:/Documents and Settings/xujm>
    C:/Documents and Settings/xujm>runmqsc TGT_QM
    5724-H72 (C) Copyright IBM Corp. 1994, 2005. ALL RIGHTS RESERVED.
    启动队列管理器 TGT_QM 的 MQSC。


    DISPLAY CHSTATUS (TGT_QM.TO.SRC_QM)
         1 : DISPLAY CHSTATUS (TGT_QM.TO.SRC_QM)
    AMQ8417: 显示通道状态细节。
       CHANNEL(TGT_QM.TO.SRC_QM)               CHLTYPE(SDR)
       CONNAME(172.16.157.128(1451))           CURRENT
       RQMNAME(SRC_QM)                         STATUS(RUNNING)
       SUBSTATE(MQGET)                         XMITQ(SRC_QM)

    C:/Documents and Settings/xujm>runmqsc TGT_QM
    5724-H72 (C) Copyright IBM Corp. 1994, 2005. ALL RIGHTS RESERVED.
    启动队列管理器 TGT_QM 的 MQSC。


    DISPLAY CHSTATUS (TGT_QM.TO.SRC_QM)
         1 : DISPLAY CHSTATUS (TGT_QM.TO.SRC_QM)
    AMQ8417: 显示通道状态细节。
       CHANNEL(TGT_QM.TO.SRC_QM)               CHLTYPE(SDR)
       CONNAME(172.16.157.128(1451))           CURRENT
       RQMNAME(SRC_QM)                         STATUS(RUNNING)
       SUBSTATE(MQGET)                         XMITQ(SRC_QM)


    原文链接:http://blog.csdn.net/jaminwm/article/details/4070197
    发布于 2年前, 阅读(32) | 评论(0) | 投票(0) | 收藏(0) 阅读全文...
回到页首