商业解决方案.doc

DB2 通用数据库和DB2 Connect 版本8提供领先的商业解决方案数据库管理软件现在是企业计算的核心。企业需要访问广泛的信息，例如XML文档，视频流以及其它丰富的媒体类型。新的工作方式带来新的需求，例如数字版权的管理。电子商务的发展要求提供连续可用性，并且随着企业不断集成他们的业务操作，要求企业集成事务、商业智能和内容管理应用。DB2通用数据库版本8可以帮助您的组织迎接这些挑战。 现在无论您企业的规模如何，都需要一个伴随您不断发展的数据库。DB2版本8就是您需要的数据库。它可以快速响应您网站的高峰交易需要，能容纳分布在不同的数据库中的日益增长的信息，并可随着您的基础设施从一个处理器扩展到多处理器，以至大型并行群集而不断发展。在新的DB2通用数据库企业服务器版中集成了分区和群集技术，这意味着它的灵活性足以满足这些需要。您无需现在就提前为未来的增长做出决策。 DB2 通用数据库版本8还增加了自管理和资源调整 （SMART） 数据库技术，使数据库管理员可以使用增强的自动化功能来配置、调整和管理他们的数据库。SMART数据库管理可使管理员在管理例行任务时花费较少的时间，将更多的时间集中到帮助企业获得和保持持久的竞争优势上。行业领先的多位群集数据表功能减少了您的DBA的索引工作量，同时提供数据群集功能，便于快速查找数据。这就意味着可以更快获得能作出更好决策的信息，支付较少的系统管理费用，并改善了数据仓库应用。DB2创新的查询重写和优化技术以及性能配置功能都在业界领先。这就意味着您可以花费更多的时间来分析业务信息，在性能改进和调整问题上花费较少的时间。 DB2内置的计划内和计划外可用性功能，确保您的业务应用在需要的时候都可用。不管在数据库意外出现故障时切换到备用数据库服务器，还是进行在线维护，DB2都确保您的业务应用保持可用。在线功能，例如重建索引，加载数据表和配置参数，都可以在不停止数据库的情况下完成，因此提高了性能和高可用性。 DB2版本8为新的世纪提供了合适的数据管理解决方案。在提供高级性能、可用性、可扩展性和易管理性方面，其它数据库都不能与版本8相比。我们邀请您一同挖掘DB2通用数据库版本8的“新功能”。 易管理性的改进 加载增强 版本8中对数据加载进行了很多改进，添加了新的功能，简化了将数据加载进分区和多个分区数据库环境的过程。加载功能现在是在表一级上完成的。这就意味着加载工具不再需要独占整个表空间，在加载操作中可以并行访问同一个表空间中的其它表对象。而且在加载操作中所涉及的表空间不会停顿。如果对可恢复的数据库指定了COPY NO选项，当加载操作开始时，表空间将处于备份待用表空间状态。在加载工具中添加的另一个特性是在加载新数据时，能够查询表中以前的数据。在LOAD命令中指定READ ACCESS选项就可以做到这一点。在这一版本中还引入了LOCK WITH FORCE选项。它使您可以强迫应用释放它们对表加的锁，使加载操作得以继续，并获得它所需要的锁。您可以使用在分区的数据库环境使用与在单个分区数据库环境中使用的相同的命令（LOAD，db2load）和API（db2load，db2LoadQuery）来加载数据，不再需要AutoLoader工具（db2atld）和AutoLoader配置文件。利用新的CURSOR文件类型，您现在可以将一个SQL查询结果加载到一个数据库中，不必将它们先导出到一个数据文件中。版本8之前的版本，对目标数据表进行加载操作之后，如果数据表中包括生成的列，它将保持在待用状态。加载工具现在可以生成列数据，您无需在对一个包含生成列并且没有其它表限制的数据表进行加载操作之后执行SET INTEGRITY语句。LOAD QUERY命令的功能也进行了扩展。它现在可以返回向其中加载数据的目标表的表状态，并可以返回加载之前的状态信息。LOAD QUERY命令可以用来查询表状态，查看是否在对一个特定的表进行加载操作。控制中心（Control Center）中现在提供一个加载向导，帮助您完成加载操作。存储管理工具在控制中心中现在提供一个存储管理工具。 在这个工具中，您可以访问存储管理视图，其中显示了一个特定的数据库、数据库分区组或表空间的存储快照。可以定期捕捉统计信息，并根据所选择的对象进行显示： 对于表空间，显示的信息来自于系统目录以及对给定表空间下定义的数据表、索引和容器的监视信息。 对于数据库或数据库分区组，显示给定数据库或数据库分区组中定义的所有表空间的信息。 对于数据库，还收集了数据库内所有的数据库分区组的信息 您可以使用在本视图中提供的信息来监视存储的各个方面，例如表空间的使用量，数据库分区组的数据分配率（数据库分发），并可捕捉数据库分区组和表空间的索引群集比率。在存储管理视图中，您还可以设定数据分配率、空间使用量以及索引群集比率的阈值。如果一个目标对象超过指定的阈值，将会向您显示警告或报警标志。日志的改进 在7.2版中引入了双日志功能（也称作版本 7 FixPak 3）。将DB2 注册变量DB2NEWLOGPATH2 设置为YES即可支持双日志功能。双日志功能仅限于在UNIX 上提供，您不能直接控制第二组日志的路径。这个路径的缺省值放置在数据库配置参数logpath 中，它的后面添加了一个2 字符。对于版本8，在所有支持DB2 UDB的平台上都支持双日志。此外，是否启用以及对第二个日志路径的配置都由数据库配置参数mirrorlogpath来控制。当为mirrorlogpath提供了一个值的时候，将启用双日志，并且这个配置参数的值就是第二个路径。 在单路径日志中，使用两个数据库配置参数： logpath 设定的是它当前位于哪里。 newlogpath 用于指定下一次激活数据库时将使用的日志路径。 这些参数在版本8中同样适用。对于在双日志配置中的第二个路径，只有一个配置参数：mirrorlogpath。使用GET DB CFG SHOW DETAIL 命令可以确定它当前的值以及在下一次启用数据库时的值，第二个值将显示在延时值列中。可定义的最大日志空间从32GB增加到256GB，从而可以支持更多并发事务，完成更多工作。 在版本8中还支持无限活动日志。这一功能使得一个活动的工作单元可以跨越主日志和归档日志，使事务可以使用的日志文件的数量不受限制。在没有启用无限活动日志时，工作单元的日志记录必须能够在主日志空间内放得下。将logsecond设置为 -1即可启用无限活动日志。无限活动日志可以用来支持所需的日志空间超过您通常为主日志分配的空间的大型任务。在版本7中引入的日志盘数据块满的功能在版本8中使用数据库配置参数blk_log_dsk_full来完成。日志盘上的数据块满功能使您可以指定DB2在活动日志路径的盘满状态下运行应用时不至于出现故障。如果启用了这个选项，DB2将每5分钟尝试一次，使您有时间解决盘满的状况，完成应用。 新的管理提示日志 DB2 现在根据日志的用途，将日志信息放置在两个不同的日志中。 管理提示日志 当发生重大事件时，DB2向管理提醒日志中写入信息。这些信息提供给数据库和系统管理员使用。众多的提示信息提供了更多的信息，补充了SQLCODE所能提供的信息。事件的类型以及所收集的信息的详细程度取决于NOTIFYLEVEL配置参数。但是，详细的诊断信息不写到这个日志中。db2diag.log错误的诊断信息记录到这个文本日志文件中。这些信息用于确定问题之所在以及为DB2客户提供支持。信息的详细程度取决于DIAGLEVEL配置参数。为UNIX提供多种服务等级 从FixPak 1开始，DB2版本8在同一系统上可同时支持多服务（FixPak）等级。这一支持仅在UNIX平台的DB2 UDB企业服务器版上提供。对多服务等级的支持使您可以： 在旧的服务等级继续支持生产环境的同时，对新的服务等级进行测试。在测试完成之后，生产环境可以切换到新的服务等级。 不同的团队可以共享一个拥有不同的DB2代码等级的系统。例如，在一段时间内开发一个应用的团队可以继续使用DB2以前一直在提供的服务等级，而另一个启动了一个新项目的团队可以使用最新的DB2服务等级。监视系统状态的工具 在版本8中，DB2引入两个新的特性，帮助您监视DB2系统的状态：Health Monitor和Health Center。这些工具为DB2通用数据库增加了一个根据例外管理功能，通知您潜在的系统状态问题，使您可以在问题真正影响到系统的性能之前解决这些问题。Health Monitor是一个服务器端的工具，一直监视着实例的状态，即使在没有用户干预的情况下也在监视。如果Health Monitor发现超出了一个预定义的阈值（例如，可用空间不够），或者它检测到一个对象出现了异常状态（例如，一个实例停止），Health Monitor将会发出报警。发生报警时，可以采取两个动作： 可以通过电子邮件来发送报警提示或是发送到一个呼机地址，使您可以联系负责这个系统的任何人。 可以执行预先定义的动作。例如，可以运行一个脚本或一个任务（从新的任务中心（Task Center）中实现）。状态指示器（health indicator）是Health Monitor检查的一个系统特性。Health Monitor中提供了这些状态指示器的一组预定义阈值。Health Monitor将您的系统状态与这些状态指示器阈值相比较，确定是否报警。利用Health Center的命令或API，您可以定制这些状态指示器的阈值设置，并定义当提供报警时应当提醒谁，应当运行哪个脚本或任务。Health Center为Health Monitor提供图形界面。您可以使用这个界面来配置Health Monitor，查看您的实例和数据库对象累计的报警状态。使用Health Monitor的向下挖掘功能，您可以访问当前报警的详细信息，并可以获得一个建议动作列表，向您建议如何解决这个报警。您可以采用其中推荐的一个建议动作来解决报警。如果所建议的动作是变动数据库或数据库管理器配置，将会向您推荐一个新的值，点击一个按钮就可以完成这个建议。在其它情况下，所做的建议将是启动一个工具进一步调查问题，例如使用CLP或新的Memory Visualizer。Health Center和Control Center通过Health Beacon集成在一起。Control Center中的Health Beacon提示Health Center中新的报警信息。在所有的Control Center窗口和笔记本中都实现了Beacon；只需点击Health Beacon即可访问Health Center。版本8中还提供了一个新的Web Health Center，可以通过Web浏览器或PDA来访问Health Monitor信息。您还可以使用新DB2命令和API从Health Monitor中获得状态信息，使您可以将DB2状态监视与现有的系统级的监视解决方案集成在一起。Health Monitor使用新的界面收集系统的状态信息，这一新的界面不会影响性能。它不会打开任何快照监视器开关来收集信息。在创建一个实例时缺省方式是启用Health Monitor；您可以使用数据库管理器配置参数health_mon来关闭它。DB2 面向Tivoli DB2版本8已经为集成到Tivoli中做好了准备。安装好一个DB2版本8产品之后，将创建所需的签名文件，以便Tivoli Inventory 和 Discovery可以查看机器，找到DB2。Tivoli Manager for DB2用于管理，包括： 启动和停止每个服务器部件的任务 恢复每个服务器部件的任务 处理每个服务器部件的监视器 可以使用事件适配器来确定应用软件是否收集或发送了事件或报警 所有桌面部件的软件发布文件包 清点所有部件的签名 Tivoli Global Enterprise Manager （GEM）管理（Level 3）连接到其它应用的所有业务应用服务器部件 以XPixmap（XPM）格式提供应用图标2型索引版本8 中添加了对2型索引的支持。2型索引的主要优势有： 对next-key加锁的使用量减到最小，提高了并发性。消除了大多数next-key锁，因为主键被标记为删除，而不是实际从索引页面中删除。有关主键锁定问题，请参考有关讨论锁对性能的影响等主题。 可以在超过255字节的列上创建索引。 数据表只有具有2型索引的情况下，才可以对这个表进行在线重组织和在线加载。 新的多维群集功能需要这种类型的索引。所有新建的索引都是2型索引，除非您要添加索引的表上已经有了1型索引。在这种例外的情况下，您将只能创建1型索引，因为对一个表不可以混合使用1型和2型索引。在版本8之前创建的所有索引都是1型索引。要将1型索引转换为2型索引，使用REORG INDEXES命令。要找出一个表中使用哪种类型的索引，使用INSPECT命令。其它的易管理性方面的改进 重命名索引DB2 现在使您可以更改索引的名称，从而节省了时间。更改现有索引的功能允许您首先创建一个新的索引，然后删除旧的索引，并更改新的索引的名称，以便它可以替代旧的索引，不会影响到您的用户的任何性能。Null值和缺省值压缩对于具有很多NULL值以及SYSTEM DEFAULT 值的表，现在您可以节省它们的空间了。AUTOCONFIGURE 命令AUTOCONFIGURE是一个新的命令，它为缓冲池的大小、数据库配置以及数据库管理器配置推荐并应用新的值。这个命令对数据库进行了初步的调整，可以再进行其它调整。AUTOCONFIGURE还可以与CREATE DATABASE命令一起使用，在数据库创建之后即进行配置。性能改进 多维群集 多维群集（MDC）提供了一个出色的方法，可灵活、连续、自动群集多维数据。这将会极大地提高查询的性能，而且大幅度降低了数据维护操作的费用，例如重组织，以及插入、更新和删除操作过程中的索引维护操作。多维群集主要用于数据仓库和大型数据库环境，它还可以用在在线事务处理（OLTP）环境中。利用MDC，可以使一个表在物理上同时群集在多个主键（或维度）上。在版本8之前，DB2仅支持使用群集索引进行单维群集数据。利用群集索引，在表中插入和更新记录时，DB2以索引中主键的顺序在页面中维护着数据的实际顺序。群集索引大量提高了大范围查询的性能，这种查询拥有包含一个或多个群集索引主键的预测。在良好的群集的帮助下，只需要访问一部分表，当页面连续时，完成预读取的性能将更高。利用MDC，这些优势将扩展到多维中（或群集主键）中。在查询的性能方面，涉及到表的多个指定维度的大范围查询的性能将会从中受益。这些查询不仅只访问包含有正确的维度数值的记录的页面，并且这些符合条件的页面将会根据范围进行分组。而且，尽管具有一个群集索引的数据表可以随着表空间的填充，解除群集，但MDC表能够自动连续维护所有维度上的群集，从而不必为了恢复数据的物理顺序而重新组织表。预读取的增强 在版本8中，可以通过创建基于数据块的缓冲池来改善预读取性能。如果提供了一个基于数据块的缓冲池，预读取代码将重新组织，并使用数据块I/O，在一个I/O中将多个页面读取到缓冲池中，极大地提高了预读取的性能。CREATE和ALTER BUFFERPOOL SQL语句的BLOCKSIZE参数定义了块的大小，将在一次数据块I/O中从磁盘上读取指定数量的页面。在缺省方式下，缓冲池是基于页面的，这就意味着磁盘上连续的页面将会预读取到内存中非连续的页面中。如果可以将磁盘上的连续页面读取到缓冲池中连续的页面中，顺序预读取的性能将会进一步改善。为了达到这一目的，您可以创建基于数据块的缓冲池。基于数据块的缓冲池中包括一个页面区域和一个数据块区域。页面区域用于非连续预读取任务。数据块区域中包括多个数据块，每个数据块包含指定数量的连续页面，这个数值称作块大小。Java UDF和存储过程的线程 数据库的例程（存储过程，UDF和方法）现在都使用一个基于线程的模型来实现，大大提高了运行众多例程的数据库服务器的性能。例程都被定义为线程安全，将在单个保护模式进程中运行。用一个进程来处理Java例程，用另外一个进程来处理非Java例程，减少了要运行大量保护模式程序的用户所需要的环境切换。对于Java例程，它同时还允许共享JVM的资源。我们要求移植到版本8的现有非Java例程都是线程安全的。Java例程的移植需要它们是线程安全的。需要更改现有例程的用户需要先删除它们，然后再重建，或者使用相应的SQL命令。连接集中器 对于具有很多相对短暂的连接的Internet应用以及类似的应用，连接集中器可以提高它们的性能，它可以有效地处理更多的客户连接。它还减少了每个连接对内存的使用，减少了上下文环境切换数量。物化查询表物化查询表（MQT）指的是根据查询结果定义的数据表，它的数据来自于它所基于的一个或多个表中得到的未处理的结果。在版本8之前，DB2 UDB支持总结表，也称作自动总结表（AST）。总结表现在被认为是MQT的一种特别类型，它的查询语句中包括一个所查询的表的GROUP BY子句。以下对MQT的改进可以提高查询的性能。查询路由的增强查询现在可被路由到MQT中，这些MQT的定义中包括一个没有经过聚合的联合。在版本8之前，一个MQT的定义中只能引用一个聚合的联合。例如，在版本8中，可以创建下面这个包含有一个联合的数据表，用来保存坏客户的客户和帐户信息。CREATE TABLE bad_account AS（SELECT customer_name， customer_id， a.balanceFROM account a， customers cWHERE status IN （delinquent， problematic， hot）AND a.customer_id = c.customer_id）DATA INITIALLY DEFERRED REFRESH DEFERRED如果一个用户查询一个帐户是否违法，DB2 UDB优化器发现这个MQT已经缓存了所请求的信息，DB2将访问BAD_ACCOUNT，而不是访问基础表ACCOUNT，从而可以提供更好的响应时间，并且可以用于返回客户信息。用于维护的物化查询表 很多客户应用维护和加载一些特别的数据表，这些表中包括预计算的数据，代表的是一个查询的结果。将一个数据表看作是一个用户维护的物化查询表，可以提高动态查询的性能。这些MQT由用户维护，而不是由系统维护。对用户维护的MQT，允许进行更新，插入和删除操作。进行一些正确的特别注册，就可以使查询优化器利用用户维护的MQT中已经包含的预计算的查询结果。昵称的物化查询表这一功能使您可以在本地的DB2通用数据库实例中缓存远程的数据。这些远程数据所处于的数据库可以是各种关系型DBMS实例，例如Oracle或Sybase，甚至可以是DB2 UDB的其它实例。MQT可以应用多个昵称和本地表。可以使用推迟刷新选项来创建这些物化查询表。对昵称或表的查询将被重写或优化为与这些MQT相关。当所有的查询条件和路由条件都满足时，将查询路由到MQT上，所获得性能将比从远程表中获得结果更高。即使昵称所基于的远程表不可用，仍然可以查询昵称。如果这个昵称上定义了一个物化查询表，而且满足所有的路由条件，查询将仅需要从MQT中获得数据。维护可以在本地使用REFRESH TABLE命令来完成（无法跟踪对远程数据库中的数据表的更新。）维护总是延后的；不支持即时刷新物化查询表（定义在昵称之上）。利用一个阶段表增量维护物化查询表您现在可以增量式刷新使用REFRESH DEFERRED选项定义的MQT。如果要增量维护一个延时刷新的MQT，必须有一个阶段表与它相关联。与一个MQT相关的阶段表是通过CREATE TABLE SQL语句创建的。当insert/delete/update语句更新了一个MQT的基础表时，作为执行这个语句的一部分，这些更改所带来的变化将会传播出来，并立即增加到一个阶段表中。对这些阶段表的变化的传播类似于增量及时刷新MQT过程中变化的传播过程。REFRESH TABLE用于增量式刷新MQT。如果一个阶段表与这个MQT关联，系统可能使用阶段表来支持MQT增量刷新。在刷新完成后，阶段表将被删除。在版本8之前，一个延时刷新的MQT将会在刷新表操作时被从头重建。MQT现在可以增量维护，性能得到了很大提高。有关阶段表将不用于增量刷新MQT的情况，参见“SQL参考”。您还可以利用这一新功能来消除由于即时维护即时刷新MQT而导致的大量的加锁竞争。如果MQT中的数据并不需要保持最新，变化将被捕捉到阶段表，并可以在任意时间中应用。可用性增强 在线重组织表DB2 现在提供两种重组织表的方法： 在线在线重组织表使应用程序可以在重组织过程中访问数据表。此外，任何具有根据方案和表明所定义的相应权限的人都可以暂停和恢复运行在线重组织表操作。 离线离线方法重组织表的速度将更快，对于您无需重组LOB或LONG数据的情况尤其适合。除非特别请求，将不再重组织LOB和LONG数据。此外，重组织数据表后，将按顺序重建索引。只读应用可以在重组织的最后阶段访问表的原始拷贝，在重组织过程中，将会使用影子拷贝替代原始拷贝，并将重建索引。在线和离线重组织都已经进行了改进，改善了对多分区数据库的支持。您可以重组织单个分区、一组分区或所有分区。在线重组织索引 DB2版本8的一个新功能是可以在使用新的REORG INDEXES命令重组织索引时读取和更新表及其现有索引。在线重组织索引的过程中，整个索引对象（即这个表的所有索引）将被重建，将会对索引对象建立一份“影子拷贝”，原来的索引和表可以继续提供读取和写入。所有更新这个表的并发事务都将被记录。一旦被记录的表变化已经写入并且已准备好新索引（影子拷贝），将可以使用新的索引。在提供新索引期间，所有对表的访问将被禁止。REORG INDEXES命令的缺省行为是不允许访问（ALLOW NO ACCESS），在重组织过程中在表上加一个独占锁，但您如果要允许其它的事务读取或更新表，可以指定为允许读访问（ALLOW READ ACCESS）或允许写访问（ALLOW WRITE ACCESS）。现在可以在大型表空间（以前的长表空间）内创建索引。对于现有索引已经超过32GB的情况，这一功能使您可以分配足够的空间来容纳在线重组织过程中将会存在的两组索引）。可配置的在线配置参数 现在可以在线设置50多个配置参数。对这些可配置的在线配置参数的变动可以立即生效，无需停止并重启实例，或是停用并激活数据库。您不必在精心调整您的系统时断开用户，这样您就可以更灵活地决定何时更改配置。主要的数据库和数据库管理器配置参数都可以在线设定。例如， catalogcache_sz、pckcache_sz、stmtheap、sortheap和util_heap_sz等内存堆都是动态的，使您可以随着负荷的变化调整内存的使用量。其它可配置参数，例如locklist size、maxlocks和dlchktime（死锁检查时间），将使您可以调整数据库系统的加锁特性，提高性能。您可以推迟对在线可配置参数的变动，以便在下一次启动实例或激活数据库时启用更改后的配置。在GET DATABASE和GET DATABASE MANAGER CONFIGURATION命令中增加了一个SHOW DETAILS选项，可以列出当前值以及将在下一次实例或数据库激活时使用的参数。在一些情况下，您可以将您正在调整的参数设定为自动，DB2将会根据系统负荷的变化自动调整它的值。例如，将maxappls设定为自动就意味着对应用的最大数量没有限制，除非内存被耗尽。对GET DATABASE和GET DATABASE MANAGER CONFIGURATION命令已经进行了修改，可以获得设定为自动的配置值以及它们的当前值。在线创建、删除缓冲池和修改它的大小 在版本8中，您不必停止数据库活动就可以更改DB2如何使用内存。您可以在DB2运行时更改您的缓冲池分配值，变动会影响内存使用的数据库和数据库管理器的配置参数。不必停止数据库的活动，您就可以添加新的缓冲池，更改现有缓冲池的大小，或是删除缓冲池。在CREATEE和ALTER BUFFERPOOL SQL 语句中添加的新的选项： IMMEDIATE， 是缺省值，将会尝试在DB2运行的时候应用所进行的改动 DEFERRED 使您可以将变化推迟到数据库激活时启用，兼容以前版本的行为。 与以前的版本相同，DROP BUFFERPOOL 命令将会立即生效。但是，在版本8中，内存可立即提供给数据库共享内存使用，并可以重新应用于其它内存分配中。 利用修改缓冲池分配以及在线更新配置参数的功能，您现在可以针对任务定制它对内存的使用。例如，如果您使用了主轮换内存分配策略来优化查询性能（大型缓冲池），您可以使用一个脚本来优化加载操作的内存使用。这个脚本将： 减小缓冲池的大小 提高工具堆和分类堆 使用针对这个加载优化的配置来运行加载操作 当加载操作完成后，将参数返回主轮换值使用性增强 DB2 Administration Server （DAS） 的增强 在DB2 版本8中，DB2 Administration Server （DAS）不再是一个实例。现在它是一个支持TCP/IP通讯的单独的服务器进程。 DAS用于协助完成DB2服务器上的任务。如果您想使用Configuration Assistant、Control Center、Replication Center或Development Center等工具，您必需运行DAS。DAS 协助Control Center、Development Center、Replication Center和Configuration Assistant 完成以下管理任务： 支持远程管理DB2服务器 提供任务管理功能，包括能够计划运行DB2和操作系统命令脚本。这些命令脚本是用户定义的。 使用Task Center可以定义任务执行计划，查看已完成任务的结果，并可以理DAS本地及远程的任务。 在Windows和UNIX 平台上，配合使用DB2 Discovery 工具，提供了一种方法来发现数据库实例、数据库以及其它数据管理服务器的方法。Configuration Assistant 和Control Center 将使用这些信息来简化和自动配置客户对DB2数据库的连接。在版本8中，DB2 Administration Server 可以运行在zSeries （仅支持OS/390 和z/OS ）和iSeries 平台上，也可以运行在所支持的Windows 和UNIX 平台上。zSeries 和 iSeries 上的DAS可以支持Control Center， Development Center， 和Replication Center，管理zSeries和iSeries上的DB2任务。Windows和UNIX上的版本8 DAS 提供了一个计划器，运行在Task Center中定义的任务，例如DB2和操作系统命令脚本。任务信息（例如要运行的命令）、与这个任务相关的计划、提醒和完成动作，以及运行结果都保存一组表中，这些表称作工具目录（Tools Catalog）。新的向导和GUI工具 增加了很多新的向导，为您创建对象、操作数据以及配置环境的每一步提供指导。 Memory Visualizer帮助您发现并修复DB2实例中与内存相关的问题。它使用可视化显示和绘制的图片，帮助您了解内存部件以及它们之间的关系。您可以从Health Center建议中调用它，也可以将它作为一个监视工具单独运行。 使用Redistribute Data向导为您的数据库分区组创建一个有效的重新发布计划。您可以使用这个向导在新添加的数据库分区上重新分布数据，可以从您想删除的数据库分区中删除数据，或是创建一个定制的重分布计划。 备份和恢复向导已经经过重新编写，简化了它们的使用。它们还支持在版本中新增加的备份和恢复特性。 使用Config Database Logging向导，可以为您的数据库配置数据日志选项。您可以指定使用循环日志，还是使用打包日志，以及您处理日志文件的方式（打包和媒介），这个向导还提出一些建议，其中包括您的主日志文件和次日志文件的大小，以及缓冲区的数量和大小。 使用Add Partitions向导，创建一个分区，并将它添加到一个或多个数据库分区组中。使用这个向导将一个新的分区添加到您的实例，将这个分区分配到一个或多个数据库分区组中，设定分区的容器，以及计划增加操作。 使用Alter Database Partition Group向导，修改现有的数据库分区组。您可以指定将一个可用的分区添加到数据库分区组中，或是从数据库分区组中删除一个已有的数据库分区。 使用存储管理视图来监视分区的数据库的存储状态。在存储管理视图中，您可以摄取数据库、数据库分区组或表空间的存储快照， 使用Load向导将数据加载到一个选定的表中。Load向导指导您完成加载配置、选择选项。您可以保存您定义的加载配置。Load向导还使您可以拷贝一个现有的加载任务，为您新的加载任务使用现有的加载任务的设置值。 使用新的Design Advisor创建DB2ADVIS推荐的一组索引。Design Advisor替代了以前版本中提供的Create Index向导。Design Advisor向您建议在您的数据库中创建哪些索引来提高一个负载中给定的一组SQL语句的性能。 现在您使用这些对象的About功能，确定在系统或实例上安装的DB2的服务等级。这一功能提供的信息与db2level命令相同，它还可以在远程服务器的一个客户端上运行。复制增强 Replication CenterDB2 Replication Center是一个新的用户界面工具，您可以用来设置和管理您的复制环境。Replication Center支持管理DB2-到-DB2的复制环境，并可以管理DB2和非DB2关系数据库之间的复制。DB2 Replication Center是DB2 Control Center工具组的一部分。Replication Center包括以前的DB2 Control Center和DB2 DataJoiner Replication Administration （DJRA）工具所提供的复制功能。您可以使用Replication Center来： 为创建控制表、源对象和目标对象定义缺省配置 创建复制控制表 注册复制源 创建订阅集合，向订阅集合中添加订阅成员 运行Capture程序 运行Apply程序 监视复制过程您可以使用Replication Center来完成众多其它的复制管理任务。Replication Center有一个启动板，使您可以完成设置DB2复制环境所需的基础功能。启动板还以图形方式向您展示不同步骤之间如何关联在一起。您不能使用版本8 Control Center来管理复制环境；请使用Replication Center来管理复制环境。在版本8中，DB2中不再提供DB2 DataJoiner Replication Administration （DJRA）工具。Capture 程序的增强 您可以以任意顺序启动Capture 和Apply程序。新的复制控制表确保Capture和Apply程序之间的有效交互，以及与Repliation Alert Monitor的通讯。Capture程序的缺省模式已经发生变化。使用这一新的缺省启动模式，在第一启动Capture程序的时候，它将进行冷启动，但在以后的重启中将仅进行热启动，不会自动切换到冷启动。在以前的版本中，Capture程序要么捕捉数据，要么删除数据，但不能同时做这两项工作。在版本8中，它可以同时做这两项工作。在Capture程序启动的时候，将启动一个独立的删除线程，在Capture程序运行期间它将一直激活。说明: 以前版本的DB2 DataPropagator for AS/400上已经有了这些改进功能。正常的以及有限保留的删除功能由这些单独的线程来完成，以便在保持数据存储占用最小资源的同时不影响吞吐性能。在启动Capture程序的时候，您可以提供运行参数。如果已经启动了一个Capture程序，您可以动态修改运行参数。Capture程序由您或Apply程序在Signal（IBMSNAP_SIGNAL）表中存放的信号来控制。这个信号表提供一种通过日志记录与Capture程序通讯的方式。这个信号表不仅使Apply程序可以告诉Capture程序何时开始捕捉数据，它还可以精确地结束日志记录读取，用户还可以通过日志记录来定义信号。Capture程序使用这些信号来确定何时开始或停止捕捉一个特定表的变化，以及它是否必需执行任意更新的复制。它还提供了日志序列号为Apply事件设定精确的结束点。在您注册一个表进行复制时，您可以指定为这个对象指定行捕捉规则。对于每个注册的表，您可以指定在这个表的一行中的任意列发生的变化，还是只有当所注册的列发生变化时才进行捕捉。例如，如果您注册了一个具有100个列的表进行复制，但您只想捕捉其中两列的变化，而且只有当这两列被更新时才进行捕捉，您可以在注册这两个表的时候指定行捕捉规则。在以前版本的DB2系统中，您不能为每个注册的表指定行捕捉规则。您必需在启动Capture程序的时候指定行捕捉规则；因此，即便您只想对很少的一部分表进行额外的处理，也要对所有的表都使用行捕捉规则。在版本8中不再提供启动参数。无需重新初始化Capture程序或是停止它然后再启动它，您就可以在您的复制源中添加列。额外的列值没有添加到变化数据（CD）表中。在UNIX、Windows和z/OS系统中，您还可以在Capture程序运行的时候更改CD表。在任意更新的复制中，对一个复制表的改订将被捕捉到，并复制到其它所有表中。如果您具有一个多层的环境，或者如果您的复制表时源表的逻辑分区，您可能不希望一个复制表的变化被传递到所有其它表中。在版本8中，您可以指定是否希望重新捕捉这些变化并传递到其它复制对象中，您是否希望Capture程序忽略另一个复制表已经捕捉到的变化。在版本7中，您只能创建一个Windows服务来运行您所有的Capture和Apply程序。在版本8中，您可以为每个Capture和Apply程序以及Replication Alert Monitor创建单独的服务，单独启动和停止它们。多个Capture 程序在给定服务器上创建多组Capture控制表，您可以运行Capture程序的多个实例。所有相关的Capture控制表都具有一个唯一的表方案，称作捕捉方案（Capture schema）。缺省的Capture 方案是ASN。您可以使用不同的运行参数启动每个Capture程序，每个程序独立运行。考虑到如下原因，您可能希望在一个服务器上使用多个Capture程序： 在单个联合服务器上支持多个非DB2关系源 在z/OS操作系统中混合支持ASCII、EBCDIC和UNICODE源表。 获得更高的吞吐量和更低的延迟Apply 程序和其它增强 在版本8中，消除了一些情况下复制控制表之间的联合，从而大大提高了性能。例如：用户拷贝的目标表无需在读取中使用联合即可填入数据。 变动数据（CD）表中的IBMSNAP_UOWID 列被替换为IBMSNAP_COMMITSEQ。IBMSNAP_COMMITSEQ 列使Apply 程序可以在处理某些对象表类型时不必将CD表与UOW表联合。 没有参与复制场合，没有检测到冲突的CD表可以不必使用联合来删除。对于需要CD表之间的联合以及UOW表的情况，可以使用IBMSNAP_COMMITSEQ列来实现联合。您可以选择让Apply程序以事务方式提交变化，按照提交序列的顺序同时提交给所有的订阅集合，而且您可以指定Apply程序在提交它的工作之前应处理多少个事务。在数据仓库中，或者如果目标表上存在引用完整性限制，这一功能将特别有用。在版本7中，您仅可以创建每个Capture和Apply程序以及Replication Alert Monitor创建单独的服务，单独启动或停止它们。在版本7中，Apply程序以及Replication Analyzer中使用的密码文件中包含的都是普通的文本，不是加密信息。在版本8中，密码文件中的密码都经过加密，所有的密码都没有采用平文本来保存。使用一个新的命令（asnpwd）可以创建和维护密码文件。监视复制过程您可以通过以下方式监视版本8中的复制环境：设置监视以便当发生某些事情的时候您可以得到通知 Replication Alert Monitor根据您设定的标准监视Capture和Apply程序。在Replication Cener中，您可以为您想监视的标准定义报警条件，并指定当达到这些条件时将自动联系谁。例如，您可以为Capture程序使用的内存量设定一个阈值。如果内存使用量超过了这个设定值，将通过Replication Alert Monitor向您指定的联系人发送报警。对于Apply程序，您可能希望定义一个报警条件，以便在任意更新配置中事务被拒绝后发送提示。您还可以指定您希望被提示发生了什么错误条件。您可以使用Replicaton Center或asnmon命令来启动Replication Alert Monitor。您可以使用一个Monitor qualifier来启动多个Monitor程序实例。能够启动多个Monitor程序使您可以在多个Monitor之间分配负载，或是确保关键事务应用拥有一个专用的Monitor集成。查询当前的复制过程和统计信息 您可以抽查复制程序进行的情况： 您可以查询Capture和Apply程序的每个线程的状态。例如，使用这种监视类型，可以确定Capture程序是在捕捉还是处于空闲状态。在Replication Center中提供每个Capture或Apply控制服务器的状态信息，也可以使用asnccmd和asnacmd命令获得状态。 您可以查看存储在某个复制控制表中的详细统计信息。使用Replication Center查看统计信息，帮助您解决任何Capture方法或Apply qualifier的问题。您可以刷新查询，更新显示区内的统计信息。分析复制统计数据的趋势和历史数据 您可以使用Replication Center来查询历史数据，按照一定的时间间隔来审查复制环境完成的情况。您可以生成报表，然后分析以下信息： 消息：Capture和Apply程序提供了哪些错误和提示性信息？ 捕捉吞吐量：平均说来，在给定的时间段内处理了CD表中的多少行记录？ 捕捉延迟：Capture程序最近何时向CD表中提交了数据？ 应用吞吐量：平均说来，在给定的时间段内处理目标表的多少行记录？ 端到端延迟：平均说来，Capture程序从DB2日志中读取变化与Apply程序将这些变化复制到目标表之间有多大的时间差？应用开发的增强 对例程的增强（存储过程，用户自定义函数和方法） 术语例程（routine）包括存储过程、UDF和方法。这反映了这样一个事实，对于DB2版本8，参数样式，数据类型映射和系统目录对于三种例程类型来说都相同。下面是对例程的主要改进：目录视图函数、方法和存储过程的目录视图现在已经合并在一起。 SYSCAT.ROUTINES 描述了在数据库中定义的所有例程 SYSCAT.ROUTINEPARMS 描述了这些例程（函数和方法）的参数，以及它们的返回信息。 仍然支持以前的目录视图，现有的依赖这些视图的应用仍然可以运行。新的调用例程的权限 例程EXECUTE的权限已经进行了明确的控制，控制谁可以调用例程（存储过程，UDF和方法）。在SQL语句中使用例程时，例程的定义者必需对这个例程要使用的所有包具有EXECUTE权限。新的注册外部例程的权限新定义了权限来明确控制谁可以注册外部例程（存储过程，UDF和方法）。要注册外部例程，需要CREATE_EXTERNAL_ROUTINE 授权。FENCED THREADSAFE 例程作为一个共享进程内部的一个线程运行。每个这样的例程都可以读取同一个进程内的其它例程线程所使用的内存。因此，一个线程化的例程可以收集这个线程化的进程中的其它例程的重要数据。共享一个进程的另一个内在的风险是一个有着内存管理缺陷的例程线程可能会破坏其它的例程线程，甚至导致整个线程化的进程崩溃。在授权CREATE_EXTERNAL_ROUTINE 时，应知道得到这一授权的人可以潜在地监视或破坏其它FENCED THREADSAFE 例程的内存。详细信息，参见“Java UDF和存储过程的线程”。要注册NOT FENCED例程，需要CREATE_NOT_FENCED_ROUTINE 授权。NOT FENCED 例程与数据库管理器运行在同一个进程内，因此，可以破坏数据库管理器的共享内存，和损坏数据库控制结构。两种损害都将会导致数据库管理器失败。NOT FENCED例程还可以破坏数据库和它们的数据表。在授权CREATE_NOT_FENCED_ROUTINE 时，应清楚地知道得到这一授权的人可以潜在地获得不受限制地访问数据库管理器以及它的所有资源的权限。如果您拥有 CREATE_NOT_FENCED_ROUTINE 权限，您也拥有CREATE_EXTERNAL_ROUTINE 权限。外部例程的ALTER 语句 每种例程类型现在都有一个ALTER语句来更改例程的EXTERNAL NAME来应用一个新的例程体。例如，在您需要更新Java 存储过程的Java方法时，不必删除后在重新注册它，可以使用ALTER