【网学网提醒】：文章导读：在新的一年中，各位网友都进入紧张的学习或是工作阶段。网学会员整理了将Teradata数据库作为MicrosoftSQLServer2000分析服...的相关内容供大家参考，祝大家在新的一年里工作和学习顺利！
将Teradata数据库作为MicrosoftSQLServer2000分析服务应用程序的源
更新日期：2004年06月15日JoyMundyMicrosoftCorporation2003年6月摘要本文介绍了针对混合OLAP(HOLAP)、多维OLAP（MOLPA）或关系OLAP（ROLAP）解决方案，构建使用SQLServer2000分析服务和Teradata数据库的最佳实践。本文的目标读者是系统集成师或数据库开发人员。我们希望读者基本了解这两个数据库系统的特性。
本页内容
简介入门设计考虑事项关系设计技巧为实现低响应时间OLAP的设计改善MOLAP处理性能设计考虑事项小结总结附录A：资源
简介
MicrosoftCorporation和Teradata（NCR的一个部门）认识到他们共同的客户可能在构建分析应用程序时，希望将双方公司的产品结合在一起使用。这种分析服务的分析数据库包括OLAP多维数据集以及可能的数据挖掘模型，而且可以
以HOLAP、MOLAP或ROLAP形式使用Teradata数据库中的数据。正如下文所要详细介绍的，使用Teradata数据库支持大部分分析服务特性。本文的前提是已经存在Teradata数据库源，而且已经定义用户查询、分析和数据响应时间要求。在您开始阅读本文之前，我们建议您先熟悉下列内容：多维模型概念，包括事实和维度、代理键（surrogatekey）以及慢变化维度。分析服务基础知识。作为最基本的知识，您应该完成分析服务2000教程，您可以从分析管理器的开始屏幕中访问这个教程。Teradata数据库基础知识，包括Teradata的物理设计技术、Teradata的数据库开放接口（例如OLEDBProviderforTeradata或ODBCDriverforTeradata）以及AggregateJoin索引等数据库特性。
Microsoft和Teradata支持的分析服务特性
使用Teradata数据库时几乎可以支持所有的分析服务特性。下表中包括使用Teradata数据库时支持的部分特性：替代存储模式ROLAP、HOLAP和MOLAP维度的关系存储用户定义的分区父-子维度链接的多维数据集从多维数据集连接到Teradata数据库分析服务的操作数据挖掘计算成员计算单元格定制滚动MicrosoftSQLServerBooksOnline（在线图书）简单介绍了这些特性。其中一篇标题为各版本SQLServer2000所支持的特性[英文]的文章详细介绍了不同版本SQLServer2000所支持的特性。大部分特性仅在SQLServer2000的企业版和开发人员版中可用。尤其需要指出的是，用户定义的分区特性在标准版中不可用。分区功能是成功地构建和部署具有Teradata数据库的大规模分析服务数据库的关键。这个问题将在本白皮书中进行讨论。我们强烈推荐您使用企业版。
Microsoft和Teradata不支持的分析服务特性
下表列出了所有Microsoft和Teradata不支
持的特性：
ROLAP聚集：当分析服务多维数据集分区使用具有Teradata数据库的ROLAP聚集：分区存储时，它必须定义为零聚集。这个问题将在稍后的“设计考虑事项”中讨论。OLAP：自动的实时OLAP：如果分析服务的实时OLAP系统构建在Teradata数据库基础上，它必须管理分析服务器的响应时间提醒。这个问题将在稍后的“设计考虑事项”中讨论。维度回写：当分析服务的分析应用程序需要维度回写时，它将无法直接在维度回写：Teradata数据库上开发。维度回写特性最常由预算和“what-if假设分析）（”应用程序所采用。对于那些希望构建或安装具有维度回写功能的应用程序的客户，我们建议他们在MicrosoftSQLServer中建立一个独立的数据集市。这个独立的数据集市可以作为分析服务分析应用程序的直接来源。单元格回写：当分析服务的分析应用程序需要单元格回写时，单元格回写：它将无法直接在Teradata数据库上开发。单元格回写特性最常由金融应用程序所采用。与维度回写一样，需要这个特性的客户可以在MicorosftSQLServer中构建一个独立的数据集市，可以作为分析服务应用程序的直接来源。返回页首
入门
安装和配置
我们建议的生产配置是在与Teradata数据库不同的另一台服务器上安装分析服务。这台分析服务器需要下列软件：操作系统分析服务正如BooksOnline文章各版本SQLServer2000所支持的操作系统[英文]中所定义的。
MicrosoftSQLServer2000分析服务（ServicePack3）或更高，版本包括：StandardEdition（标准版）EnterpriseEdition（企业版），含有标准版所没有的扩展特性集DeveloperEdition（开发人员版），特性等同于企业版
很多客户在他们的开发服务器上使用DeveloperEdition。如果您在生产环境中使用StandardEdition，那么您需要注意一些在DeveloperEdition中可用的特性无法在StandardEdition中使用。这些差别在BooksOnline文章各版本SQLServer2000所支持的特性[英文]中有详细介绍。连OLEDBProviderforTeradata或通ODBCDriverforTeradata与MicrosoftOLEDBProviderforODBC(与性MicrosoftSQLServer一同安装)相结合。参考Microsoft知识库文章KB822215，可以了解有关Teradata数据库连通性软件当前版本的信息。
分析服务配置在安装了这个产品后，需要立刻对许多分析服务设置进行修改。为了提高性能、可靠性和管理性，将分析服务元数据存储库迁移到了一个专用的Server数据库。在安装时，这个元数据存储库被存储在MicrosoftAccess数据库中。您可以在任何时刻迁移这个存储库，但是最好立刻就完成这个迁移。在迁移这个元数据存储
库时，选择本机（Native）格式，不要选择元数据服务（MetadataServices）格式。我们建议在更改多维数据集数据或元数据时，您的系统管理程序应该备份这个元数据存储库。将分析服务元数据存储库隔离在其自己的SQLServer数据库中，这样能够简化备份日程安排的设计。在默认情况下，进程缓冲的大小被设置为32MB。大部分执行MOLAP或HOLAP处理的应用程序都能够从更大的进程缓存中获益。欲了解详细信息，请阅读分析服务性能指南[英文]中的“分析服务如何使用和管理内存”一节。测试连通性为了测试连通性，首先需要检验分析服务是否已经在开发计算机上正确安装。启动分析管理器（AnalysisManager），浏览Foodmart2000数据库的定义。重新处理一个维度或多维数据集。如果您以前没有使用过分析服务，我们建议您完成分析管理器“入门”屏幕中的教程。接下来，检验与Teradata数据库的连通性。在分析管理器中，创建一个新的数据源，指向Teradata数据库。在数据源创建向导的第一页上，选择OLEDBProviderforTeradata，如下图所示：下图显示了数据源创建向导的提供者屏幕。
查看大图。在数据连接属性对话框的连接选项卡中，输入连接到Teradata数据库所需的信息。下面的例子显示了一个指向Teradata1服务器的连接。您也可以连接到特定的IP地址。请注意，必须选中“允许保存密码”复选框。下图显示了数据源创建向导的连接屏幕。
查看大图。使用“测试连接”按钮来测试与Teradata数据库的连通性。通过在数据连接属性对话框的“所有”选项卡中编辑扩展属性，您可以设置许多OLEDBProviderforTeradata的参数。您最可能感兴趣的参数包括：最大响应大小使用x视图默认数据库会话模式有关其他配置选项和故障诊断技术的信息，请参考OLEDBProviderforTeradata安装和用户指南[英文]。当您使用分析管理器维度向导和多维数据集向导时，您选择从哪个数据库取得维度或多维数据集。为了确保连通性正常工作，请创建和处理一个较小的维度。使用一个常用Teradata数据库中非常小的表作为源表。如果您可以创建和处理一个维度，那么这个数据源就已经正确地被定义了。返回页首
设计考虑事项
除了上面所介绍的不支持的特性以外，来源于Teradata数据库的OLAP多维数据集的逻辑设计与来源于其他源的多维数据集是相同的。目前针对设计和构建分析服务数据库的大部分最佳实践都是假定数据来源于SQLServer关系数据库的。除了下面所列出的几处例外以外，大部分的这些建议仍然适用于来源于Teradata数据库的数据：索引
类型等数据库特有的特性。特别需要指出的是，AggregateJoin索引等Teradata数据库特性可能为聚集数据的关系查询提供显著的性能提高。Teradata数据库和分析服务数据库之间带宽的考虑事项。为了在两个系统间传输数据，拥有良好的网络连通性以及优化配置的OLEDB提供者是非常重要的。当分析服务分区存储为MOLAP模式时，在分区处理过程中这个问题尤为重要，稍后将详细讨论。虽然不论数据是来源于SQLServer还是Teradata数据库，基本原则是相同的，但不同的特征仍将导致对不同物理设计方法的成本和收益的不同评价。因此，对分析服务多维数据集的结构、处理、存储模式和查询等的基本特性进行评估将是非常有用的。这些信息对于评价不同的设计方案尤为重要。分析服务多维数据集和维度分析服务数据库包含维度和多维数据集。维度类似于（通常来源于）关系维度表。多维数据集类似于（来源于）关系事实表。大部分维度都在多个多维数据集间进行共享。多维数据集由两类事实数据组成：叶子层和聚集。叶子层事实是包含在多维数据集中的细节事实数据。通常，多维数据集的粒度与其来源的事实表的粒度是相同的。也就是说，多维数据集所包含的叶子层行数与关系源表所包含的一样多。在其他时候，多维数据集的粒度要高于源事实表：多维数据集最底层实际上是源事实表的聚集。虽然创建有用的聚集是提供多维数据集查询性能的唯一最重要的途径，但聚集仍然是非强制性的选项。由分析服务所创建的多维数据集事实数据和聚集数据存储在一个或多个分区中。如果多维数据集具有多个分区，它通常根据用于切分查询所用的维度进行分区。时间是最常用的分区维度。正如分析服务性能指南[英文]中所讨论的，分区对于提高查询和处理性能都是很有价值的，同样对于多维数据集的管理性也很有用。一个分区的多维数据集可以：同时处理多个分区。每个分区具有不同的聚集设计。每个分区具有不同的存储模式。
通过查询中的分区排除来提高查询性能。我们强烈推荐分区的多维数据集。这个特性需要企业版SQLServer2000。分析服务处理如果您要完全处理一个分析服务数据库，那么第一步将是处理维度。在几乎所有的情形中，维度数据都从关系数据库中提取到分析服务引擎中，经过验证，然后以分析服务维度格式写入分析服务器。维度的关系存储是一种例外，稍后在本白皮书中将简要的加以讨论。接下来是处理数据库中的所有多维数据集，也就是处理每个多维数据集中的每个分区。多维数据集分区处理本身由两
步组成：叶子事实处理和聚集处理。完全处理相对并不常见。在最初装载了历史数据后，定期的（通常每天、每周或每月）处理将是增量式的。组成增量处理的步骤与完全处理的一样，但是仅处理添加到关系存储中的维度成员和事实数据。附录A给出了很多参考资料，详细介绍了分析服务的处理过程。分析服务查询分析服务查询是由客户端工具生成的，例如MicrosoftExcel数据透视表（PivotTable）。这个查询以多维表达式（MDX）语言传送到客户端或中间层组件（称为PTS）。PTS拥有一个数据缓存，如果可能能够从这个缓存中来解答查询。如果PTS缓存没有包含所请求的数据，它会对分析服务器发出请求。同样，分析服务器也拥有一个缓存，可以在所有用户间共享。如果从服务器缓存无法解答查询，那么服务器会从永久性存储中请求数据。服务器将从可用来解答查询的最高层聚集那里获取数据；然后将所获得的单元集聚集成所请求的级别；并计算所有结果，例如计算成员等。计算成员以MDX进行定义，可以非常简单：MeasureA-MeasureB。但它也可以用非常复杂的MDX表达式，隐含地请求大量的叶子数据。在设计多维数据集和评估查询性能时，请记住，看上去十分简单的计算成员（例如“前10名客户的平均销售量”）为了进行计算可能需要大量的叶子数据，这一点非常重要。在这个例子中，对于前10个客户的动态评估可能是开销非常大的操作。即使叶子数据以ROLAP或HOLAP存储模式存储在关系数据库中，这类评估也总在分析服务器上进行。分析服务存储模式分析服务支持以三种模式的分区数据存储：
MOLAP叶子数据和所有聚集都以分析服务格式存储在分析服务器上。在处理过程MOLAP中，叶子数据被从关系源中提取出来，以分析服务格式存储在分析服务器中。聚集以分析服务格式进行计算和存储。MOLAP存储是最常用的分析服务存储模式，在查询时间方面实现了最高的性能。当Teradata数据库和分析服务数据库之间的带宽很差时，MOLAP分区完全处理的速度将受到OLEDB提供者的影响。在设计多维数据集管理系统时必须考虑到这一点，使多维数据集的完全处理具有足够高的性能。大部分MOLAP多维数据集需要相应源数据（存储在关系数据库中，仅包括数据，不计算索引）的20-30%存储空间。叶子MOLAP数据需要其中大约一半的存储空间，而另一半则由聚集占用。具有DistinctCount量度的多维数据集具有更大的聚集。ROLAP细节数据和聚集（如果有）存储在关系数据库中。正如前面所提到的，在ROLAPTeradata数据库/分析服务配置中，不
支持由分析服务创建的ROLAP聚集：在这种情况下，ROLAP存储是具有零聚集的ROLAP，在存储设计向导中进行定义。为了确保ROLAP的聚集被设置为0，请运行存储设计向导，并在设置聚集选项面板中将性能粒度设置为0%。这种情形下的聚集需要通过TeradataAggregateJoin索引特性来创建。如需了解有关实施AggregateJoin索引的更多信息，请参考Teradata数据库和客户端用户文档。通常，维度以分析服务格式存储在分析服务器上，这样能够提供极其快速的维度浏览用户体验。在查询时，分析服务引擎通过确定客户端应用程序所请求的多维数据集单元来解答数据请求，然后向关系数据库发出一个或多个查询。所有计算都在这些数据上执行，例如计算成员、计算单元或定制滚动等，其计算单元集将被发送回客户端应用程序。如果所有多维数据集分区都存储为ROLAP模式，那么多维数据集维度可能也存储在Teradata数据库中。这种体系结构非常精明，是一种受支持的配置。但是，这种配置并不常见。ROLAP存储模式诱人之处在于其低响应时间的数据发送，通常被称为实时OLAP。这个问题稍后将在“设计低响应时间OLAP”一节中进一步详细讨论。HOLAP细节数据存储在Teradata数据库中，聚集以MOLAP格式存储。在处理过HOLAP程中，细节数据从Teradata数据库中提取，但是不进行存储；聚集以分析服务格式进行计算和存储。HOLAP分区的处理时间与具有相同聚集设计的MOLAP分区几乎相同。虽然MOLAP分区在分区服务器上几乎需要两倍于HOLAP分区的存储空间，但我们并不推荐HOLAP分区。如果您可以为足够的处理性能设计多维数据集处理应用程序，您应该能够从叶子数据的MOLAP存储中获益，它需要相对较
MOLAP叶子数据和所有聚集都以分析服务格式存储在分析服务器上。在处理过程MOLAP中，叶子数据被从关系源中提取出来，以分析服务格式存储在分析服务器中。聚集以分析服务格式进行计算和存储。MOLAP存储是最常用的分析服务存储模式，在查询时间方面实现了最高的性能。当Teradata数据库和分析服务数据库之间的带宽很差时，MOLAP分区完全处理的速度将受到OLEDB提供者的影响。在设计多维数据集管理系统时必须考虑到这一点，使多维数据集的完全处理具有足够高的性能。大部分MOLAP多维数据集需要相应源数据（存储在关系数据库中，仅包括数据，不计算索引）的20-30%存储空间。叶子MOLAP数据需要其中大约一半的存储空间，而另一半则由聚集占用。具有DistinctCount量度的多维数据集具有更大的聚集。少的磁盘空间成本。不论采用哪
种存储模式，除了可能的性能差别以外，多维数据集的行为在各个方面都是相同的。在查询时，大部分计算都在分析服务数据库引擎中进行。如果在使用ROLAP或HOLAP的分区中解答一个查询需要关系数据，那么分析服务引擎会向Teradata数据库发送相对简单的查询。除了在多维数据集分区处理过程中，MOLAP多维数据集都无法访问Teradata数据库。返回页首
关系设计技巧
大部分针对构建分析服务多维数据集的文档和最佳实践都建议维度化地构建关系源。维度关系模型有两种表结构：维度以前维度被处理为经典的单表星型维度结构，现在完全规范为雪花型维度，或是介于两者之间的混合结构。分析服务维度是从维度表结构而来的。当然，如果源数据模型非常不规范，那么也可以从事实表来构建分析服务维度。事实用于多维数据集中一个分区的事实必须存储在一个表或视图中——也就是说，您不能将“每日”和“每月”粒度的数据混合在一个事实表中。事实表包含维度表的外部键索引。多维数据集是从一个事实表以及一个或多个维度来创建的。内存需求正如需要资料中详细介绍的，特别是分析服务性能指南[英文]，分析服务器必须拥有足够多的内存来保存所有维度成员。在维度处理过程中，服务器必须拥有足够的内存来保存被处理维度的副本。性能指南中提供了有关如何计算内存需求
的信息，但是这是分析服务多维数据集的基本特性，对多维数据集设计有着巨大影响。如果您的维度成员和成员属性太多，无法存放到内存中，那么您可以选择下列三种方法之一：修改多维数据集设计，取消过多的维度。维度的关系存储（前面已讨论）SQLServer2000分析服务（64位）支持非常多的维度，但是需要64位OLEDB驱动程序来连接到关系数据库。在撰写本文的时候，仍没有64位的OLEDBProviderforTeradata。取消过多的维度似乎是一种折中方案，但实际上它经常是最佳的解决方案。商业用户很少需要在分析过程中看到单个客户的名称。通常，定义更多的聚集维度，使得能够通过Drillthrough或Actions来查看细节数据，这是满足商业用户需求的更高途径。关系架构需求作为分析服务数据库基础的数据模型必须符合一个简单的维度结构：星型架构、雪花型架构或简单的平面表。这些模型可以进行混合。例如，在同一个分析服务数据库中，一些维度可以来源于一个典型的星型维度表，其他的可以来自于完全规范的“雪花”表，也可以有一些来源于事实表的数据。虽然我们建议在事实和维度表之间使用完整代理键，但分析服务不要求这样
做。对于大型数据集，特别是大型维度，请为键使用尽可能小的数据类型。当维度被处理时，分析服务检验维度层次之间的索引完整性，确保所有的子维度成员都具有合法的父维度。相类似的，在多维数据集处理过程中，分析服务检验事实和所有维度之间的索引完整性。如果一个事实在所有维度中没有相对应的成员，那么它将不会被允许存在于多维数据集中。将视图作为多维数据集源从关系视图获取分析数据库，而不直接从表来获取，这是一个很常见的最佳实践。这种间接的方法提供了一种在关系和分析数据库之间的隔离层。在最简单的情况下，您可以将视图定义为"select*fromPhysicalTable"。如果在维度结构中并没有关系源数据，那么可以定义简化关系结构的视图，来实现一个逻辑维度数据库。将Order/Detail表结构转换成一个单独的Fact_OrdersLineItems视图就是这样的一个例子。我们建议您仔细检查为分析用户开发商业需求以及设计逻辑维度模型的过程。这个逻辑维度模型应该非常接近于您构建的分析服务维度和多维数据集。是否重新建立规范的数据仓库，物理地说明Teradata数据库的维度结构，这个决策取决于：
维度变更管理需求。很多商业用户需要跟踪维度结构或属性的变更历史。如果没有物理地创建维度关系模型，要实现这个功能（被称为“第2类变更维度”）是很困难的关系查询性能，针对MOLAP分区的多维数据集全局查询，以及针对ROLAP分区的商业用户查询。使维度键最小化针对大型分析服务数据库，为维度ID使用较小的数据类型是很好的方法。请记住，所有维度都必须适合于内存——较小的键将使得维度大小最小，减少内存需求并提高性能。对于MOLAP多维数据集，叶子事实多维度结构将维度ID作为它的键。通过使用较小的键，您可以使得ROLAP或MOLAP事实结构的磁盘存储需求最小，并提高性能。一般维度仓库的经验是为维度使用整型代理键。在更改维度成员时，您会创建一个新的维度成员和代理键，并这个代理键传播到事实表中，此时除了评估问题以外，还有很多填充和维护维度数据仓库的工作。Teradata数据仓库通常不是维度的，因此可能没有代理键。如果存在代理键，那么请在分析服务维度的定义中将其指定为维度ID。优化用于MOLAP存储的架构很多分析服务实践和白皮书都讨论了“优化架构”的重要性。这个过程将多维数据集定义为：系统为多维数据集处理和ROLAP查询生成简化的关系查询。在大部分系统中，这一步能够为MOLAP处理带来显著的改善。构建在Teradata数据库中的多维数
据集可能会发现，使用TeradataJoin或AggregateJoin索引会使得这一步不再那么重要。虽然如此，从关系查询中提取多个维度表格的成本经常是零，因此对于使用MOLAP存储的多维数据集而言，让建议采用这一步。详细的操作说明可以在BooksOnline中找到，题目为优化多维数据集架构[英文]。如果部署了TeradataAggregateJoin索引，那么请不要以这种方式来优化架构。Teradata数据库查询优化器更推荐采用由默认（非优化的）多维数据集定义所生成的查询语法。父-子维度和ROLAP存储分析服务支持标准维度，具有固定的已知数量的命名层，它也支持父-子维度，这种维度的结构性稍差。如果有分区存储在关系数据库中，那么我们不建议使用父-子维度。索引Teradata数据库一些分析服务多维数据集构建的粒度与源Teradata数据库相同；其他多维数据集的粒度更高。例如，关系数据可能包含具有一天以内时间戳的事务，但粒度可
能不包含time-of-day维度。在这种情况下，请在与多维数据集相同的粒度级别上构建一个AggregateJoin索引，这样能够显著提高用户查询ROLAP存储的性能。如果多维数据集使用ROLAP存储，那么添加一个或多个AggregateJoin索引可能能够显著地改善性能。您可以对用户查询进行分析，从中找出应该构建哪个AggregateJoin索引。这项工作可以通过数据库查询日志功能（TeradataDatabaseV2R5或更新版本中）或访问日志功能（早期版本的TeradataDatabase）来实现。在关系架构中加入AggregateJoin索引可能对整体维护策略产生潜在的影响。AggregateJoin索引可能会增加数据管理基础构架的成本。为了优化用户查询性能，可以选择具有AggregateJoin索引的ROLAP存储模式，或者MOLAP存储模式。我们支持HOLAP存储模式，很少选择MOLAP。为了使Teradata数据库优化器更好地完成工作，我们建议在装载后对所有表进行统计。如果后来的数据更改显著地改变了表数据统计，我们还建议您定期重新计算统计。虚拟多维数据集分析服务OLAP数据库通常包含多个物理多维数据集，这些物理多维数据集经常被组成一个或多个虚拟多维数据集。对于户查询分析服务数据库而言，虚拟多维数据集的外观和行为与物理多维数据集并没有差别。它是一种强大分析设计构造，经验丰富的设计者可以用它：为不同的用户组提供多种用户体验。简化复杂的物理结构。使得用户能够对来自多个事实表的组合数据进行查询。返回页首
为实现低响应时间OLAP的设计
一个或多个多维数据集分区的关系存储能够实现低响应时间或“实时”OLAP。具有低响应时间的OLAP
应用程序意味着商业用户能够在事务完成后很快就获得分析数据。如果分析服务应用程序需要低响应时间，那么上游过程必须填充具有低响应时间的Teradata数据库。另一种低响应时间设计如果多维数据集包括至少一个ROLAP分区，那么将能够实现非常低的响应时间。很多客户以MOLAP分区存储大部分多维数据集，但同时拥有一个具有零聚集的ROLAP分区，用来保存低响应时间的数据。例如，ROLAP分区可以保存“今天”
或“本周”的数据。在这种配置中，每晚或每周的处理过程可以将ROLAP分区转换成MOLAP。如果需要，可以将多维数据集所有的分区都保存为ROLAP分区。对于管理维度更改，有着更多的选择和挑战。在最常用的配置中，维度存储在多维存储中。对于已有维度成员（例如，已有客户）的新事务可以实现低响应时间的分析。定期进行（每晚或更频繁）维度增量处理，可以使新增维度成员能够用于分析。如果客户需要为维度更改的低响应时间访问，他们必须使用维度的关系存储，也就需要对于所有多维数据集分区的关系存储。我们建议您仅针对动态维度使用关系维度存储，而对静态维度使用一般的多维存储。其他的技术材料还介绍了一个用于低响应时间的流行技术——根据自动的时间表对多维数据集进行增量处理，例如每5-15分钟。清空缓存前面曾提到过，分析服务将试图使用本地和服务器缓存来解析查询。在低响应时间应用程序中，缓存导致了查询结果矛盾的风险。比如，两个查询同步执行，其中一个在聚集级别，而另一个在细节级别。在这个例子中，假定聚集查询从本地或服务器缓存获得答案，而细节查询必须从RDBMS给以解答。细节查询将接受所有新的事务，因此细节数据的聚集可能与来自缓存的聚集查询结果并不一致。您无法关闭缓存；因此必须定期清空缓存。正如“分析服务不支持的特性”中所讨论的，Teradata数据库并不支持自动的实时OLAP。这个特性只针对从SQLServer2000关系数据库构建的多维数据集，并且依赖于关系和分析服务器之间的通讯来清空缓存。清空缓存并不困难；您可以从分析服务性能向导的附录C中获得VBscriptCacheFlusher.vbs。CacheFlusher.vbs必须在分析服务器上运行。清空服务器缓存将自动相客户端缓存发送消息，来清除它们的内容。您可以在分析服务器上设置日常安排，每N秒运行一次CacheFlusher.vbs。或者，您可以编写一个监视Teradata数据仓库的应用程序，在插入或更新数据行时触发这个VBscript。在低响应时间环境中，查询性能总会降低，因为缓存不再那么有用。返回页首
改善MOLAP处理性能
分析服务性能向导为如何提高MOLAP多维数据集处理性能提供了很多建议。通常，所有这些建议都适用于从Teradata数据库构建的多维数据集。TeradataMOLAP实现方式最显著的差别在于平行处理的重要性以及建议的平行度。正如本文前面所讨论的，MOLAP分区处理的瓶颈最可能出现在Teradata数
据库和分析服务之间的通讯上。当这个通讯通道受到限制时，它能够处理比其他分析服务技术文档所推荐的数量更多的平行分区。您应该一直在您自己的环境中测试平行处理，找出最佳性能。常见的情况是，分析服务事实和聚集处理是控制因素，大部分技术文档建议您为每个分区分配两个CPU。在有限带宽的情况下，您可以平行处理更多的分区，每个CPU处理一个或多个分区，这样能够提高性能。在一台4x700MHz处理器服务器上进行简单的实验中，对10个分区的平行处理性能进行了测试，每个分区具有160,000个数据行（总共一百六十万行）、30个MOLAP聚集，它们来自于一个双节点的Teradata数据库。在这个应用中，在分析服务器上，平行处理4个分区是最好的选择，能够提供3倍于串行处理的性能。系统所能获得的最快处理速率是每分钟300,000行（包括读取、写入叶子事实以及计算和写入聚集）。这个系统受到通讯通道的限制。对于多维数据集的偶尔全部刷新而言，MOLAP处理性能是最关键的问题。很多商业智能（BI）应用程序能够接受的每日或每周增量处理速度是平行处理每分钟300,000行（包括读取、写入叶事实以及计算和写入聚集）。在分区处理过程中，查询可以使用预更新的多维数据集映象。MOLAP存储提供了最可靠的查询性能。构建在Teradata数据库上的分析服务应该平行的处理分区。详细信息请参考分析服务性能指南[英文]以及SQLServer2000ResourceKit[英文]中的平行处理实用程序。返回页首
设计考虑事项小结
在Teradata数据库上实现分析服务数据库时会遇到很多技术挑战，其中最大的挑战是确定存储数据的方式和位置。这里总结了三种最常用的选择。
无分析服务聚集的ROLAP，使用AggregateJoin索引：这种配置能够为大部分
用户查询提供卓越的查询性能，它也最适合低响应时间应用程序。表中的AggregateJoin索引需要仔细地设计数据装载情形。
无分析服务聚集的ROLAP，无AggregateJoin索引：这种配置能够为大部分
用户查询提供卓越的查询性能，它最适合非常低响应时间的应用程序。
MOLAP：MOLAP配置能够为用户查询提供最一致的高性能存储方式。但是，当
具有受限的通讯带宽时，处理MOLAP多维数据集所需要的
时间可能是无法接受的。如果这个多维数据集需要在投入生产之后进行完全的重新处理，那么就更可能无法接受了。在下列情况时，建议使用MOLAP存储：1)多维数据集增量处理时间满足系统要求，2)需要适应资源分区情形。在具有受限通讯带宽的系统中，当维度更改使多维数据集结构失效时，它需要对MOLAP分区进行费时的重新处
理。同样的维度更改也可能触发ROLAP分区的重新处理，但是在Teradata数据库中的这些分区具有零聚集，因此处理起来也很快。您可以在分析服务性能指南[英文]中找到关于触发重新处理的维度更改类型的深入讨论。HOLAP配置将细节数据保存在Teradata数据库中，而将聚集保存在分析服务多维结构中。相对于MOLAP而言，这种配置并不常用。返回页首
总结
对于创建世界级的分析环境而言，分析服务和Teradata数据库可以互为补充。这两个产品为解决方案的实施提供了空前的灵活性，因此在正确的理解用户需求后，实施者能够以最适合的方式构建解决方案。返回页首
附录A：资源
MicrosoftSQLServer2000BooksOnlineMicrosoftSQLServer2000ResourceKit分析服务性能指南[英文]白皮书MicrosoftDeveloperNetworkLibrary[英文]MicrosoftBusinessIntelligence站点[英文]Teradata站点[英文]Teradata数据库和客户端用户文档，地址：info.ncr[英文]。
