五种提高SQL性能的方法
发布日期：4/1/2004|更新日期：4/1/2004JohnnyPapa
DataPointsArchive
有时，为了让应用程序运行得更快，所做的全部工作就是在这里或那里做一些很小调整。啊，但关键在于确定如何进行调整！迟早您会遇到这种情况：应用程序中的SQL查询不能按照您想要的方式进行响应。它要么不返回数据，要么耗费的时间长得出奇。如果它降低了报告或您的企业应用程序的速度，用户必须等待的时间过长，他们就会很不满意。就像您的父母不想听您解释为什么在深更半夜才回来一样，用户也不会听你解释为什么查询耗费这么长时间。（“对不起，妈妈，我使用了太多的LEFTJOIN。”）用户希望应用程序响应迅速，他们的报告能够在瞬间之内返回分析数据。就我自己而言，如果在Web上冲浪时某个页面要耗费十多秒才能加载（好吧，五秒更实际一些），我也会很不耐烦。
为了解决这些问题，重要的是找到问题的根源。那么，从哪里开始呢？根本原因通常在于数据库设计和访问它的查询。在本月的专栏中，我将讲述四项技术，这些技术可用于提高基于SQLServer?的应用程序的性能或改善其可伸缩性。我将仔细说明LEFTJOIN、CROSSJOIN的使用以及IDENTITY值的检索。请记住，根本没有神奇的解决方案。调整您的数据库及其查询需要占用时间、进行分析，还需要大量的测试。这些技术都已被证明行之有效，但对您的应用程序而言，可能其中一些技术比另一些技术更适用。
本页内容
从INSERT返回IDENTITY内嵌视图与临时表避免LEFTJOIN和NULL灵活使用笛卡尔乘积拾遗补零
从INSERT返回IDENTITY
我决定从遇到许多问题的内容入手：如何在执行SQLINSERT后检索IDENTITY值。通常，问题不在于如何编写检索值的查询，而在于在哪里以及何时进行检索。在SQLServer中，下面的语句可用于检索由最新在活动数据库连接上运行的SQL语句所创建的IDENTITY值：
SELECT@@IDENTITY
这个SQL语句并不复杂，但需要记住的一点是：如果这个最新的SQL语句不是INSERT，或者您针对非INSERTSQL的其他连接运行了此SQL，则不会获得期望的值。您必须运行下列代码才能检索紧跟在INSERTSQL之后且位于同一连接上的IDENTITY，如下所示：
INSERTINTOProducts(ProductName)VALUES('Chalk')
SELECT@@IDENTITY
在一个连接上针对Northwind数据库运行这些查询将返回一个名称为Chalk的新产品的IDENTITY值。所以，在使用ADO的VisualBasic?应用程序中，可以运行以下语句：
SetoRs=oCn.Execute("SETNOCOUNTON;INSERTINTOProducts_(ProductName)VALUES('Chalk');SELECT@@IDENTITY")
lProductID=oRs(0)
此代码告诉SQLServer不要返回查询的行计数，然后执行INSERT语句，并返回刚刚为这个新行创建的IDENTITY值。SETNOCOUNTON语句表示返回的记录集有一行和一列，其中包含了这个新的IDENTITY值。如果没有此语句，则会首先返回一个空的记录集（因为INSERT语句不返回任何数据），然后会返回第二个记录集，第二个记录集中包含IDENTITY值。这可能有些令人困惑，尤其是因为您从来就没有希望过INSERT会返回记录集。之所以会发生此情况，是因为SQLServer看到了这个行计数（即一行受到影响）并将其解释为表示一个记录集。因此，真正的数据被推回到了第二个记录集。当然您可以使用ADO中的NextRecordset方法获取此第二个记录集，但如果总能够首先返回该记录集且只返回该记录集，则会更方便，也更有效率。
此方法虽然有效，但需要在SQL语句中额外添加一些代码。获得相同结果的另一方法是在INSERT之前使用SETNOCOUNTON语句，并将SELECT@@IDENTITY语句放在表中的FORINSERT触发器中，如下面的代码片段所示。这样，任何进入该表的INSERT语句都
将自动返回IDENTITY值。
CREATETRIGGERtrProducts_InsertONProductsFORINSERTASSELECT@@IDENTITYGO
触发器只在Products表上发生INSERT时启动，所以它总是会在成功INSERT之后返回一个IDENTITY。使用此技术，您可以始终以相同的方式在应用程序中检索IDENTITY值。
返回页首
内嵌视图与临时表
某些时候，查询需要将数据与其他一些可能只能通过执行GROUPBY然后执行标准查询才能收集的数据进行联接。例如，如果要查询最新五个定单的有关信息，您首先需要知道是哪些定单。这可以使用返回定单ID的SQL查询来检索。此数据就会存储在临时表（这是一个常用技术）中，然后与Products表进行联接，以返回这些定单售出的产品数量：
CREATETABLE#Temp1(OrderIDINTNOTNULL,_OrderDateDATETIMENOTNULL)
INSERTINTO#Temp1(OrderID,OrderDate)SELECTTOP5o.OrderID,o.OrderDate
FROMOrdersoORDERBYo.OrderDateDESC
SELECTFROM
p.ProductName,SUM(od.Quantity)ASProductQuantity#Temp1t
INNERJOIN[OrderDetails]odONt.OrderID=od.OrderIDINNERJOINProductspONod.ProductID=p.ProductIDGROUPBYp.ProductNameORDERBYp.ProductName
DROPTABLE#Temp1
这些SQL语句会创建一个临时表，将数据插入该表中，将其他数据与该表进行联接，然后除去该临时表。这会导致此查询进行大量I/O操作，因此，可以重新编写查询，使用内嵌视图取代临时表。内嵌视图只是一个可以联接到FROM子句中的查询。所以，您不用在tempdb中的临时表上耗费大量I/O和磁盘访问，而可以使用内嵌视图得到同样的结果：
SELECTp.ProductName,SUM(od.Quantity)ASProductQuantityFROM(SELECTTOP5o.OrderID,o.OrderDateFROMOrderso
ORDERBYo.OrderDateDESC)tINNERJOIN[OrderDetails]odONt.OrderID=od.OrderIDINNERJOINProductspONod.ProductID=p.ProductIDGROUPBYp.ProductNameORDERBYp.ProductName
此查询不仅比前面的查询效率更高，而且长度更短。临时表会消耗大量资源。如果只需要将数据联接到其他查询，则可以试试使用内嵌视图，以节省资源。
返回页首
避免LEFTJOIN和NULL
当然，有很多时候您需要执行LEFTJOIN和使用NULL值。但是，它们并不适用于所有情况。改变SQL查询的构建方式可能会产生将一个花几分钟运行的报告缩短到只花几秒钟这样的天壤之别的效果。有时，必须在查询中调整数据的形态，使之适应应用程序所要求的显示方式。虽然TABLE数据类型会减少大量占用资源的情况，但在查询中还有许多区域可以进行优化。SQL的一个有价值的常用功能是LEFTJOIN。它可以用于检索第一个表中的所有行、第二个表中所有匹配的行、以及第二个表中与第一个表不匹配的所有行。例如，如果希望返回每个客户
及其定单，使用LEFTJOIN则可以显示有定单和没有定单的客户。
此工具可能会被过度使用。LEFTJOIN消耗的资源非常之多，因为它们包含与NULL（不存在）数据匹配的数据。在某些情况下，这是不可避免的，但是代价可能非常高。LEFTJOIN比INNERJOIN消耗资源更多，所以如果您可以重新编写查询以使得该查询不使用任何LEFTJOIN，则会得到非常可观的回报（请参阅图1中的图）。
图1：查询
加快使用LEFTJOIN的查询速度的一项技术涉及创建一个TABLE数据类型，插入第一个表（LEFTJOIN左侧的表）中的所有行，然后使用第二个表中的值更新TABLE数据类型。此技术是一个两步的过程，但与标准的LEFTJOIN相比，可以节省大量时间。一个很好的规则是尝试各种不同的技术并记录每种技术所需的时间，直到获得用于您的应用程序的执行性能最佳的查询。
测试查询的速度时，有必要多次运行此查询，然后取一个平均值。因为查询（或存储过程）可能会存储在SQLServer内存中的过程缓存中，因此第一次尝试耗费的时间好像稍长一些，而所有后续尝试耗费的时间都较短。另外，运行您的查询时，可能正在针对相同的表运行其他查询。当其他查询锁定和解锁这些表时，可能会导致您的查询要排队等待。例如，如果您进行查询时某人正在更新此表中的数据，则在更新提交时您的查询可能需要耗费更长时间来执行。
避免使用LEFTJOIN时速度降低的最简单方法是尽可能多地围绕它们设计数据库。例如，假设某一产品可能具有类别也可能没有类别。如果Products表存储了其类别的ID，而没有用于某个特定产品的类别，则您可以在字段中存储NULL值。然后您必须执行LEFTJOIN来获取所有产品及其类别。您可以创建一个值为“NoCategory”的类别，从而指定外键关系不允许NULL值。通过执行上述操作，现在您就可以使用INNERJOIN检索所有产品及其类别了。虽然这看起来好像是一个带有多余数据的变通方法，但可能是一个很有价值的技术，因为它可以消除SQL批处理语句中消耗资源较多的LEFTJOIN。在数据库中全部使用此概念可以为您节省大量的处理时间。请记住，对于您的用户而言，即使几秒钟的时间也非常重要，因为当您有许多用户正在访问同一个联机数据库应用程序时，这几秒钟实际上的意义会非常重大。
返回页首
灵活使用笛卡尔乘积
对于此技巧，我将进行非常详细的介绍，并提倡在某些情况下使用笛卡尔乘积。出于某些原因，笛卡尔乘积(CROSSJOIN)遭到了很多谴责，开发人员通常会被警告根本就不要使用它们。在许多情况下，它们消耗的资源太多，从而无法高效使用。但是像SQL中的任何工具一样，如果正确使用，它们也会很有价值。例如，如果您想运行一个返回每月数据（即使某一特定月份客户没有定单也要返回）的查询，您就可以很方便地使用笛卡尔乘积。图2中的SQL就执行了上述操作。
虽然这看起来好像没什么神奇的，但是请考虑一下，如果您从客户到定单（这些定单按月份进行分组并对销售额进行小计）进行了标准的INNERJOIN，则只会获得客户有定单的月份。因此，对于客户未订购任何产品的月份，您不会获得0值。如果您想为每个客户都绘制一个图，以显示每个月和该月销售额，则可能希望此图包括月销售额为0的月份，以便直观标识出这些月份。如果使用图2中的SQL，数据则会跳过销售额为0美元的月份，因为在定单表中对于零销售额不会包含任何行（假设您只存储发生的事件）。
图3中的代码虽然较长，但是可以达到获取所有销售数据（甚至包括没有销售额的月份）的目标。首先，它会提取去年所有月份的列表，然后将它们放入第一个TABLE数据类型表(@tblMonths)中。下一步，此代码会获取在该时间段内有销售额的所有客户公司的名称列表，然后将它们放入另一个TABLE数据类型表(@tblCus-tomers)中。这两个表存储了创建结果集所必需的所有基本数据，但实际销售数量除外。第一个表中列出了所有月份（12行），第二个表中列出了这个时间段内有销售额的所有客户（对于我是81个）。并非每个客户在过去12个月中的每个月都购买了产品，所以，执行INNERJOIN或LEFTJOIN不会返回每个月的每个客户。这些操作只会返回购买产品的客户和月份。
笛卡尔乘积则可以返回所有月份的所有客户。笛卡尔乘积基本上是将第一个表与第二个表相乘，生成一个行集合，其中包含第一个表中的行数与第二个表中的行数相乘的结果。因此，笛卡尔乘积会向表@tblFinal返回972行。最后的步骤是使用此日期范围内每个客户的月销售额总计更新@tblFinal表，以及选择最终的行集。
如果由于笛卡尔乘积占用的资源可能会很多，而不需要真正的笛卡尔乘积，则可以谨慎地使用CROSSJOIN。例如，如果对产品和类别执行了CROSSJOIN，然后使用WHERE子句、DISTINCT或GROUPBY来筛选出大多数行，那么使用INNERJOIN会获得同样的结果，而且效率高得多。如果需要为所有的可能性都返回数据（例如在您希望使用每月销售日期填充一个图表时）则笛卡尔乘积可能会非常有帮助。，但是，您不应该将它们用于其他用途，因为在大多数方案中INNERJOIN的效率要高得多。
返回页首
拾遗补零
这里介绍其他一些可帮助提高SQL查询效率的常用技术。假设您将按区域对所有销售人员进行分组并将他们的销售额进行小计，但是您只想要那些数据库中标记为处于活动状态的销售人员。您可以按区域对销售人员分组，并使用HAVING子句消除那些未处于活动状态的销售人员，也可以在WHERE子句中执行此操作。在WHERE子句中执行此操作会减少需要分组的行数，所以比在HAVING子句中执行此操作效率更高。HAVING子句中基于行的条件的筛选会强制查询对那些在WHERE子句中会被去除的数据进行分组。
另一个提高效率的技巧是使用DISTINCT关键字查找数据行的单独报表，来代替使用GROUPBY子句。在这种情况下，使用DISTINCT关键字的SQL效率更高。请在需要计算聚合函数（SUM、COUNT、MAX等）的情况下再使用GROUPBY。另外，如果您的查询总是自己返回一个唯一的行，则不要使用DISTINCT关键字。在这种情况下，DISTINCT关键字只会增加系统开销。
您已经看到了，有大量技术都可用于优化查询和实现特定的业务规则，技巧就是进行一些尝试，然后比较它们的性能。最重要的是要测试、测试、再测试。在此专栏的将来各期内容中，我将继续深入讲述SQLServer概念，包括数据库设计、好的索引实践以及SQLServer安全范例。创建于：2005-08-1120:34:25，修改于：2005-08-1120:34:25，已浏览545次，有评论0条
鱼的天地
我是一条喜欢自由自在的飞鱼||我羡慕天空的空旷和自由||我也深爱大海的深度和广度smithy.cublog首页|文章|相册|收藏夹|留言
IBMDB2备份
B2备份简介
了大量时间同客户和用户组谈关于DB2UniversalDatabaseforLinux、UNIX?和Windows?(DB2)中最新、最重要特性的承诺。但事实总是
一个话题时，如果问听众他们是否熟悉一项新的关键特性，即使这项特性已经存在有一段时间了，大多数人还是没有听说过这项特性。在本文中，我们将
次BACKUP实用程序之旅，并展示该实用程序在DB2中的工作原理。我们将谈到它的内部组成，以及已经增加了有一段时间的一些新特性，这些新特
度更快，功能更丰富。
要备份？
什么应该定时进行备份（并测试这些备份的可恢复性），有很多的原因。备份中的数据对您虽然没什么用，但它却是您企业的救命稻草，所以把备份数据
作吧。
况都需要备份：为了在出现应用程序错误时进行恢复，为了复制数据库（例如，填充开发或测试系统），为了将数据库转移到新的硬件上，为了迁移到一
，为了确保软件更新保护前后的可恢复性，为了建立某种灾难恢复（DR）或高可用性（HA）拓扑结构，等等。
是，如今人们做备份的最大原因是确保能够在出现应用程序错误时进行恢复。可以说，如今的硬件（H/W）已经相当安全了。例如，双电源、RAID、双
非常接近标准，如果一切设置无误的话（显然有例外），遭受H/W停机事故的几率很小。但如何才能避免人为的错误呢？
是
备份而不是文件系统备份？
的数据库管理员（DBA）都会问这个问题。主要原因是，DB2在努力保持热缓存（实际上是在内存中应用程序所需的数据）方面非常主动。随着64-位
，这会成为一种趋势，并且这种趋势不会减缓（也不应该减缓，因为能够放在处理器的L1、L2或L3缓存或随机存储器中的数据越多，工作负载就运
际上，您需要积极主动的数据缓存，因为它使数据尽可能远离磁盘，从而避免高代价的I/O周期。
2在运行的时候，如果要拷贝一个文件系统上的文件，那么肯定会导致数据的不一致，DB2不能保证可以恢复数据。例如，如果数据库在运行，那么执
制操作时将得不到即时点（pointintime,PIT）上数据库的快照。您应该坚持使用DB2备份来确保数据的一致性——否则，如果不终止整个DB2
无法确保数据的一致性。
有了基于DB2的备份，就可以利用DB2的在线能力，它允许在备份过程中执行DDL和DML，这样业务操作就可以像往常一样继续。由于可以在表
备份，所以还可以进行粒度控制。这样可以将那些关键的表分离出来进行备份，而留下其他那些不需要备份或者不需要经常备份的表。
备份还有助于可恢复性。您可以通过日志前滚到所选择的某个PIT上。换句话说，您可以细粒度地控制系统在“起死回生”时的样子，而不是像使用文件系
样只是得到一个静态的快照（这种快照很可能是不一致的）。
还支持“子集（subset）”恢复。例如，如果备份5个表空间，那么可以选择只恢复其介质出现故障的那个表空间。而在文件系统备份中，要么是全部恢
也不恢复。
DB2
备份实用程序通常被集成在DB2引擎中，它不是一个附带的实用程序。我们曾经提到，DB2备份实用程序具有粒度控制能力。备份镜像（backupim
以下任何组合：
?数据库或一系列的表空间。?离线或在线。?完全（full）、增量（incremental）或差异（delta）。
用程序有很多“调节器（knob）”，这些调节器可用于对备份进行调优（从DB2V8.2开始，调优将自动完成——后面有更详细的讨论）。例如，可以
参数包括：如何使用进程读或写数据库，用于写到目标介质的缓冲区的数目和大小，等等。
中的备份实用程序对数据页进行物理上的复制。这种备份不是文件系统的备份，而是逻辑上的备份。DB2备份镜像包括数据以外的附加信息，例如元数据
置、历史文件、表空间定义，等等。
一个系统时，DB2将数据从磁盘读入到它的输入/输出（I/O）缓冲区，并将这些数据从缓冲区写到目标设备或第三方存储管理软件（例如IBMTivoliSt
ger）。从DB2V8.2开始，对于在线备份，日志文件是备份镜像的一部分（显然，离线备份不需要日志文件就可以进行恢复）。值得注意的是，临时表
DMS盘区（extent）不是备份镜像的一部分。DB2备份实用程序还具有压缩功能（从DB2V8.1.4开始）和throttling功能（从DB2V8.2开
在本文的后面讨论这些功能。
有一个非常高效的备份实用程序，它可以将从数据库读出的数据页分成多个部分，并以随机的顺序将它们写到目标设备。换句话说，数据页完全不是按照
质上的表关联顺序存放的。DB2这样做是为了优化备份实用程序的性能（我们假设备份要多于恢复）。DB2备份实用程序还支持原始设备。
中提供了三种不同的备份方式：
?完全备份使您得到完整的备份（有时候也称0级备份）。?增量备份捕捉自上一次完全备份以来的所有变化（有时候也称1级备份）。?最后，差异备份捕捉自上一次任何类型的备份以来的一切变化（有时也称2级备份）。
确地配置数据库使之提供相关的支持，就可以在数据库或者表的级别上进行这些类型的备份，还可以在线或离线进行备份。
程模型
必要讨论一下DB2备份进程模型。如果知道DB2生成的进程在做些什么，则有助于理解系统的性能。图1解释了DB2中的备份进程。
备份进程模型
可以看到DB2表空间和它们相关的容器。当调用备份实用程序时，DB2将生成db2agent进程，以便控制缓冲区操纵者（db2bm进程用于将数据
共享内存）与db2med进程（从共享内存读数据并将数据页写出到目标设备）之间的流。
程的运行速度没有限制，但是，您可以根据自身环境的工作负载通过DB2的throttling功能控制它们的速度。为了为这个实用程序设计尽可能快的架
区操纵者编写代码时，已经使它不必将数据发给特定的控制器。这就像是一场“赛跑”——DB2不关心数据页在备份介质上的存放顺序，只关心数据页到
的速度有多快。
据页之间还是有一定的关联：每个表空间将被指定给一个单独负责处理该表空间中所有数据的进程。缓冲区操纵者的数量由调用备份实用程序时的paral
制。例如，如果将此选项设置为2，那么将会有两个db2bm进程，每个进程并行地读取两个不同的表空间。
db2med进程数等于目标数。例如，对于TivoliStorageManager，如果想要打开三个会话，DB2就会建立三个到Tivoli服务器的流。这将帮助D
档介质的并行性。
备份数据到一个文件系统，并且这个文件系统是多个磁盘的一个虚拟系统，那么应该多次指定挂载点（mountpoint）例如，Windows环境下的DB。在
入以下命令：
1.当文件系统是多个磁盘的一个虚拟系统时，备份数据到这个文件系统
kupdatabasesampletoc:c:c:
例子中，DB2将生成3个到存档介质的db2med进程，然后并行地将数据页从db2bm进程写到这三个进程。
份
份首先在V7.2版中找到立身之处。由于它是被首先引入的，我们已见证了这种类型的备份受欢迎程度的日益增加——尤其是在只有很小一部分数据
仓库中。
份允许只备份自上一次备份以来发生变化的索引和数据页。不过有一个例外，对于“脏（dirty）”表空间中的long型字段和大型对象数据，总是需要进行
一类的数据没有增量支持，因为这些数据类型具有不同于索引和数据页的物理格式，目前DB2在备份时不确定这样的数据是否有变化。在以后版本的D
外就不复存在。
展示了DB2中提供的不同类型的部分备份方式：
增量备份和差异备份
图中可以看到，增量备份实际上是以上一次的完全备份为基础。由于完全备份是在星期天进行的（在我们的例子中是如此），这意味着在星期二进行的增
括星期一和星期二的所有变化。
份以上一次的增量备份或差异备份为基础。对于差异备份，需要维护自上次完全备份以来采取的所有备份，以便能够重构数据。例如，为了将数据恢复到
结束时，需要星期一、星期二和星期三的差异备份镜像（或星期三的日志文件）。如果在星期二做了增量备份，那么只需要星期二的增量备份镜像以及星
备份镜像（或日志文件）即可。
生变化的数据页之外，增量备份还包括数据库的元数据（数据库配置、历史文件、表空间定义等），以便在恢复时起到辅助作用。元数据不是增量复制的
都一一完全复制。
况下，DB2数据库没有被配置为支持增量备份，因为为了使DB2能执行这类备份，会对运行时性能产生一个非常小的影响。要启用这种备份，可以将
KMOD数据库配置参数设置为ON（对这个参数的更改要到下一次数据库活动时才生效）。
用了TRACKMOD，则第一个写操作将把数据的主机表空间标记为“脏（dirty）”。如果这个表空间不是脏的，那么在备份开始的时候，DB2完全不会理
到一个表空间中有一个脏位（dirtybit），它将继续检查作了标记的表空间中的盘区（这些表空间也用脏位作了标记），最终DB2只将发生了变化的数
备份镜像中。用于支持增量备份的跟踪特性完全是内部的，不需要考虑任何存储方面的因素。
非增量备份之前，增量备份是不允许的，非增量备份为增量备份奠定了基础，以便后者可以恢复——这是为了支持总需要非增量基础镜像的增量存储。
份
可以执行在线备份或离线备份。在对数据库进行常规的SELECT、INSERT、DELETE和UPDATE活动的同时可以执行在线备份。在DB2中运行在线
约束是：当一个表空间正在被备份的时候，不能删除这个表空间。
线备份，DB2知道应用程序只是从数据库中读取数据，因此无需担心锁的问题。而对于在线备份，事情就有所不同。DB2必须为在线备份实现一个锁策
型对象和long字段数据，DB2将IntentNone(IN)锁升级为Share(S)锁，因而要慢大约10%。
份很可能需要从UTIL_HEAP内存分配中得到更多的内存，以便为一些帮助支持这种操作的内部结构分配内存。
历史
历史文件正成为数据库引擎中越来越关键的部分。数据库历史文件是对管理操作的一种记录。任何类型的备份镜像都在各自存储数据库历史文件（它是我
提到的元数据的一部分）。在历史文件中的事件记录包括诸如备份、恢复、日志前滚、装载、数据库或表空间的queiscing、表空间的修改以及被删除的
的表的恢复被支持时）。与记录的操作有关的信息包括：受影响的对象（数据库、表空间或表）、位置和设备类型（备份镜像或装载复制）、相关日志文
操作的起始和完成时间，以及产生的SQLCA代码等。以前，数据库历史文件是一种信息文件，您可以对其进行查询。现在DB2使用该文件来支持可恢
动恢复。新的日志管理器也使用这种文件。
息被放在一个文件中，而不是放在DB2表中，因为需要这种信息来执行恢复操作。如果数据库不可用，那么就不能利用它来进行数据库恢复。因此，数
据存储在一个ASCII文件中，并放在备份镜像中，我们可以从中检索和处理它。
备份
支持
间DB2用于写出数据的介质进程（mediaprocess）是构建在一套公布的接口之上的，从1993年开始这些接口就已经向开发市场提供。这导致对当
流备份供应商的广泛DB2支持，包括IBMTivoliStorageManager(TSM)、VeritasNetBackup、LegatoNetWorker、CompuerAssociates
应商可以使用这些接口来将他们的存档解决方案集成到DB2中，如图3所示：
DB2备份接口
份信息“插入”到供应商的存档软件中时，DB2不是将备份信息写入到文件中，而是将备份数据写入这些接口，然后以位流的形式直接将它们发送到目标
器。
如果使用TSM，那么DB2将装载TSMAPI等。这些库被直接装载到DB2内核中，并在我们的地址空间中运行。您无需担心供应商插入式代码（从
P11开始）的质量，因为DB2将保护实例地址，使其不受第三方代码失效的影响。实际上，在执行每个操作之前，DB2都将获取以前的信号处理程序的
后重现设置它们。这意味着，即使供应商的代码中断，数据库引擎也不会停机（但很显然，备份操作本身将失败）。
与TivoliStorageManager的集成已有很长的历史。实际上，DB2是第二个曾经支持TSMAPI的应用程序。由于DB2与Tivoli（实际上它是一种
悠久的集成历史，所以我们直接免费发布对TSM的支持。
StorageManager提示和技巧
置DB2来使用TSM是件很简单的事。
您需要运行dsmapipw实用程序（以具有管理权限的用户身份）以设置TSM密码。，该实用程序位于sqllib\adsm目录中。这个实用程序对用于节点的
行加密，并将其存储到磁盘上。在使用TSM和DB2时，人们碰到的60%的问题都是由于这一步执行失败而引起的。如果没有正确设置密码，那么
137错误码。
，导出特定于DB2TSM的环境变量。有三个可以设置的环境变量：
?DSMI_DIR是TSM客户机的安装目录。?DSMI_CONFIG是设置TSM时所在的配置。?DSMI_LOG指定记录任何错误的文件。
实例时，所有这些设置都将被捕捉，因此，改变其中任何一个设置（以及第一次设置DB2，使其使用TSM时）都必须重新启动实例。如果更改了任何
需重新启动实例即可。例如，如果您更改了TSM配置文件中的任何特定的TSM设置（例如您想与某台TSM服务器通信），则无需重新启动数据库
境变量通常位于DB2实例的用户配置文件中。
以时间戳来惟一地标识所有备份。DB2在TSM服务器上并不使用期限（expiration）策略。这一点很重要，因为它意味着您的备份不会过期，因此需
划来处理这种情况。
2V7中，DB2不会删除备份，而是将它们标记为非活动（inactive），所以需要设置TSM，以便保留非活动的备份（这不是默认设置）。在DB2V
况有所变化。现在，当您想要删除一个备份时，不管TSM管理类的定义如何，都可以执行删除操作。
2V7中，如果使用TSM在节点上备份一个数据库，那么只有执行该备份的用户才能恢复这个数据库。这在DB2V7环境中会导致一些问题，为了恢
务器，您必须“伪装”成原先的节点，并且要知道它们各自的密码。您必须在目标节点上创建一个空的数据库，设置TSM_NODENAME、TSM_PASSW
OWNER数据库配置参数，然后在dsm.opt文件中更改PASSWORDACCESS=PROMPT，再将NODENAME注释掉。
2V8.2中，通过附件的“供应商选项”支持，已经消除了这种复杂性。该特性允许将初始参数直接发送到TSMAPI，其中包括生成备份镜像时所在节点
DB2实例的初始ID。您不再需要知道节点TSM的初始密码。将一个备份镜像恢复到任何节点需要两步：1.在生成备份镜像之后，必须使用db2adutl授权选项将访问该镜像的访问权限授给所需的节点。例如：
db2adutlgrantnewuseronnodenamenewhostfordbmydb
2.在新的目标节点上，必须在备份命令中使用'options'字段。例如：
db2restoredbmydbusetsmoptions'fromnode=originalnodefromuser=originalinstance'
在DB2V8中，随着db2audtl实用程序的引入，对于在TSM服务器上如何管理DB2备份也有所增强。之前，由于DB2的命名惯例，对备份的
一定程度的复杂性。DB2为备份文件命名，因而您不能依赖TSM管理类来管理它们，因为它们有惟一的名称，并且永远不会过期。
udtl命令有7个选项：
?DELETE：用于将备份标记为非活动（低于DB2version8的版本），删除备份（DB2version8）和删除日志。对于低于DB2version8的版本
将标记非活动DB2数据库备份对象，以便基于相关管理类中的备份复制组backupcopygroup）（定义执行删除操作。在运行TSMExpireInve
命令时，将从TSM服务器上删除被标记要删除的对象。为了让db2adutl能够删除数据库备份，必须为TSM将Backdel参数设置为yes。为行对节点信息的更新来设置。
除保存在TSM服务器上的DB2日志，需要为节点设置ArchdelYes参数。这些参数可以在注册TSM节点时指定，也可以通过在TSM服务
?QUERY：列出在这个节点上创建的所有或特定的DB2对象。可以使用Showinactive子句来查看已经被标记为非活动的备份镜像。
?EXTRACT：从TSM对象创建磁盘镜像。如果一个数据库镜像标记为非活动，那么它就不能再被恢复，但是仍然可以从TSM服务器提取该数据库镜
务器上立即过期。
而被提取的镜像可用于执行恢复。注意，在DB2version8中，db2adutl用于删除一个对象，它不只是将对象标记为非活动，而是将其设为在T
?VERIFY：从V6开始，还有一个VERIFY选项随db2adutl实用程序发布。它允许从TSM服务器读取镜像，并在它上面执行验证。通过TAM
db2ckbkp实用程序（以前称为dumpimage）基本上是验证镜像是否可恢复的一种方法。
?GRANT：为任意主机上的任意用户提供访问db2备份镜像和日志文件的能力，这些镜像和日志文件与发出GRANT选项的节点上生成的数据库有关
份镜像和日志文件的。数据库相关的db2备份镜像和日志文件的。
?REVOKE：为任意主机上的任意用户提供撤销访问权限的能力，这些访问权限是针对与发出REVOKE选项的节点上生成的特定或全部数据库相关的d
?QUERYACCESS：为任意主机上的任意用户提供查询被授予的访问权限的能力，这些访问权限是针对与发出queryaccess选项的节点上生成的特定
整起见，下面的代码展示了DB2V7中对TSM的支持：
DB2V7中的TSM支持
2V8中，这个表看上去是这样的：
DB2V8中的TSM支持
V8.1
版本中BACKUP中的新特性
节中，我们将讨论DB2V8.1以及其他后续版本中引入的新特性。
V8.1.2
2V8.1.2中，我们支持通过throttling来限制备份实用程序。这是一个非常强大的特性，那些竭尽全力遵从严格的服务水平协议（SLA）的DBA们
这个特性。
我们来确定问题。在文中我们已提出，设计DB2备份实用程序时需要一直牢记一件事：性能。这正是我们的客户要求我们做的。当客户询问性能的时候
的是日益缩水的批处理窗口，而不得不花越来越多的精力去维护越来越小的维护窗口。于是世界变了。业务环境变成一个24x7连续可用的东西，它不
任何事而停止。
刺意味的是，那些要求我们尽可能快地完成备份实用程序的客户，现在又要求我们找到一种办法让它慢下来。因此，又引入了实用程序调节的概念。
序调节使您可以为备份实用程序定义一个策略，以便通过设置一定百分比的“正常操作”，使该实用程序不会影响生产工作负载——换句话说，它将限制
用的资源。根据业务环境中不同的因素，您可以加快、减慢或暂停这个实用程序。
展示了说明调整（throttle）一个实用程序（例如备份）的效果的例子。
备份实用程序对性能的影响——您认为不需要进行调节吗？
的图中可以看到没有运行备份时的吞吐量（每分钟事务数）。当BACKUP全力运行时，这个系统的事务率会下降到100Tpm以下。调整允许您设置
（non-adaptive）的事务率（该数字表明允许对生产工作负载的影响程度），以便根据环境定制BACKUP的吞吐量。
SLA以每分钟只维护300多个事务为基础，那么您可能要设置一个70%的非自适应调节率（throttlerate，意即BACKUP在消耗资源时需保证对
响只有30%）。于是DB2将调整BACKUP的可用资源，这样，对生产工作负载的平均影响就会是30%。
V8.1.4
2V8.1.4中，我们通过一个可选的压缩特性和一些新的TSM集成命令（GRANT和REVOKE）增强了备份实用程序。
要求DB2压缩数据库备份。备份实用程序在到达磁盘之前在缓冲区中压缩数据。数据是通过一个修改后的Lempel-Zev(LZ)算法（在"ATechniq
PerformanceDataCompression,"Welch,TerryA.,IEEEComputer,vol.17,no.6(June1984),pp.8-19中有描述）在被从数据库中读出
认的算法是平台无关的，因此可以将来自AIX机器上DB2的备份放到HP机器上的DB2上（littleendian编码只能放到littleendian编码的数据
bigendian编码的备份镜像也是如此）。
通过备份实用程序的开放插件特性提供自己的压缩算法。如果您已经指定了自己的压缩库，而丢失了您的机器，那么不用担心！DB2会将您的算法的可
到备份镜像中，因此我们还可以恢复您的镜像。
图展示了一个通过使用DB2BACKUP压缩算法来节省空间的示例。在这个例子中，我们使用压缩选项备份了一个典型的ERP数据库。备份的大小大
B变为30MB。
备份压缩结果
场测试中，一个完全随机化的数据库（由ASCII字符和数字组成）从250MB变为185MB。
这种压缩是基于软件的，因此它所带来的好处是以系统额外的CPU周期为代价的。例如，在ERP例子中，备份时间从56分钟增加到1小时46分
如果网络的带宽是一个瓶颈的话，压缩会有所帮助，因为随着备份镜像的缩小，通常您可以体验到介质I/O时间减少了。
V8.2.4还引入了新的TSMGRANT/REVOKE命令，在本文前面TSM提示和技巧一节db2adutl的讨论中，对这个命令进行了描述。
V8.2
V8.2在BACKUP领域引入了很多增强。首先，备份实用程序现在是自我调优的（或者至少在调优方面做得更好）。实际上，在大多数情况下，您不必
缓冲区的数量指定什么值，决定所需的并行度或者缓冲区的大小。图8中展示了分别运行DB2V8.2和DB2V8.1中BACKUP的一些例子。
自我调优备份
2V8.2中，备份实用程序对于缓冲区数量、并行度和缓冲区大小有自主的、优化的设置。这些设置是由DB2根据表空间数量、每个表空间的EXTENT
CPU数量以及可用内存而精心挑选的。
行BACKUP命令时，如果是从一个API调用BACKUP，而在调用该命令时，前面提到的任何参数中有未指定且没有被设为0的，那么DB2将为您
设置。
V8.2还为DB2引入了警告功能，它可以提醒用户需要备份，或者真正地执行备份，或者在警告同时执行备份。这比按一定周期调度数据库备份要更胜
定义触发备份操作的业务级策略。例如，自上次备份以来所消耗的总日志空间可以触发一个自动的备份。那些不希望DB2为他们做任何事情的DBA
个功能来接受DB2的电子邮件通知，当DB2根据DBA定义的策略断定是时候再执行一次备份时，DBA就可以收到这样的邮件——当然，DB2
调节结合在了一起，以确保生产环境不受影响。
数据库和表空间的在线备份镜像将包括一组日志文件，在将备份镜像恢复到某个一致的时间点时，这些文件是必需的。这使客户机可以发布一个单独的对
复站点，后者允许客户将数据库恢复到一个一致的时间点。在我们的经验中，很多客户机在做备份时没有备份日志文件，因此在出现故障时，就无法进行
能只可用在在线备份中，通过在调用备份命令时指定"includelogs"便可以使用这项功能。在恢复期间，日志文件只从备份镜像中提取，如果提供了
ARGET字段，并且设置了LOGSONLY参数，那么只能从备份镜像提取日志文件，而不是从数据库数据中提取。
料
?您可以参阅本文在developerWorks全球站点上的英文原文。?在DB2TechnicalSupport可以找到Version8InformationCenter和PDF产品手册之类的参考资料。?DB2UDB专区中包含关于DB2UDBforLinux、UNIX和Windows的最新信息，其中有很多文章详细谈到了最新特性。
介
DaleMcInnis拥有新不伦瑞克大学（UniversityofNewBrunswick）的计算机科学学士学位以及多伦多大学（UniversityofToronto）的电管理、备份和恢复、数据链（datalink）技术，最近还担任了高可用性架构师。
学硕士学位。Dale于1988年加入IBM，从1992年开始一直在DB2开发小组工作。在此期间，Dale一直致力于DB2内核的开发，包括
PaulC.Zikopoulos拥有BA和MBA学位，是IBMGlobalSalesSupport团队的一名获奖撰稿人和发言人。他有七年以上的DB2方面的
而且还写了许多关于DB2的期刊文章和书籍。Paul为很多杂志撰写过有关DB2的文章，并且与他人合著了以下书籍：DB2-TheComplet
Reference、DB2FundamentalsCertificationforDummies、DB2ForDummies和ADBA'sGuidetoDatabasesonLinux。Paul方面获得DB2认证的解决方案专家。您可以通过paulz_ibm@msn与他联系。创建于：2006-10-1216:33:29，修改于：2006-10-1216:33:29，已浏览413次，有评论0条
位在DRDA和Cluster/EEE方面获得DB2认证的高级技术专家（DB2CertifiedAdvancedTechnicalExpert），以及在商业智能和数据库
网友评论
发表评论昵称：匿名
提交
版权所有ChinaUnix.net页面生成时间：0.33932
