Project REAL分析服务技术探讨

和分析服务交互的三种方法

有三种方法来和分析服务交互：SQL Server管理环境(Management Studio)，项目模式下的商业智能开发环境(Business Intelligence Development Studio)和连接模式下的商业智能开发环境。我们将逐一的实施检验它们，并将向你描述如果你不能适当的结合这些工具方法，将带来的无穷麻烦。

SQL Server 管理环境（Management Studio）

在你启动SQL Server 管理环境之后，系统会直接连接分析服务的服务器，并能马上完成请求连接的操作。

例如：如果你处理一个Cube或者维度，系统内部将使用受控的API，也被称为分析管理对象(Analysis Management Objects ，AMO)，通过这些对象来查找信息以及请求管理功能，例如：对象处理。一些操作是通过AMO来实现的，另外一些是采用XMLA脚本来实现，但是无论是那种方法，都是依靠运行的分析服务服务器来完成的。由于分析服务支持并发访问，系统保留了结构上锁的特性，用来避免在多个操作并发的时候产生的冲突，例如：当某个维度正在被一个操作处理时，这个结构能够阻止试图删除这个维度的操作。

SQL Server 管理环境（Management Studio）是作为一个管理应用程序而被设计的。它并不是一个开发环境。它允许你用它来浏览分析服务（Analysis Services）服务器和执行各种相关的操作活动,例如执行备份和恢复；同步服务器；配置服务器等。当SQL Server管理环境完成基本对象管理时，例如更改少量的属性或者删除对象，它就需要依靠其它的程序来设计和配置分析服务对象。

BI Development Studio 项目模式 (默认模式)

想要设计和实现 Analysis Services 数据库的开发人员和数据库管理员可以利用BI Development Studio 与 Analysis Services 相合作。BI Development Studio 是运用 Microsoft Visual Studio® shell 构建而成的。利用BI Development Studio 完成操作与利用其他SQL Server 工具完成操作非常类似（例如创建一个集成服务包或者产生一个服务报告）。 Visual Studio shell 的一个原则就是开发是一个反复编辑，构建，配置的迭代过程。

对于Analysis Services来说，这就意味着你一旦开始了一个Analysis Services项目，你便与Analysis Services服务器分离开来。起初，你通过如下任意方式构建项目：1）从相关资源中创建维度，cube和其他对象，为Analysis Services server创建项目。2）从服务器中获取一个已有的Analysis Services数据库，并在库中创建项目。一旦项目被创建，它便与Analysis Services服务器分离开来（并且和其存在的数据库也分离开来）。你可以在飞机中或是家中利用便携式电脑脱机的获取项目。仅当你重新与Analysis Services服务器连接。

当开发项目时，BI Development Studio将检查对象在项目中和Analysis Services服务器中的不同。这些不同点用于同步项目与Analysis Services服务器。这就意味着创建了在脱机状态下创建的新对象，编辑了在脱机状态下改变的属性，删除了在项目中没有但是在Analysis Services服务器中存在的对象。

这是一个非常强大的范例。开发人员开发一个应用程序，然后进行编译和配置。从创建开始，项目可以脱机的存在于开发人员的工作站中，在工作站里项目可以被编辑，开发，然后被重新编译，配置。这也是用于Analysis Services项目的同样范例。

如何确保两个开发人员不对同一段代码冲突编辑？BI Development Studio运用了一个资源控制系统。任何人在通过相同的资源控制系统工作时，两个开发人员就不可能同时操作同一段代码了。BI Development Studio项目中的文件也是用了上述的方法保证避免冲突。这种方法也应用于项目子文件，例如组成项目的维度和cube正如组成应用程序的C＃程序源文件一样。

BI Development Studio直接联机模式

你可能认为有了这两样工具所有事情都可以做到了：操作人员使用的SQL Server Management Studio和开发人员使用的BI Development Studio。然而，在有些环境下，数据库管理员和操作员需要BI Development Studio的功能去完成他们的工作。事情就是这样的，例如，当你需要知道哪个cube有着什么样的尺寸，或者需要知道完整计划时。为了实现这个目的，BI Development Studio提供了一个直接联机模式。进入此模式需要在启动BI Development Studio后，在File菜单中选择Open选项，然后选择Analysis Services database。

在这种模式下，你不能使用脱机的项目。相反，你将直接联接到Analysis Services服务器上。如果你创建了一个分区，cube，或者维度时，你将直接创建，更新，删除对象。你将工作在运行的数据库中。在这里没有脱机编辑因此也就没有开发和迁入的基础文件。

如何陷入麻烦

很明显你能注意到这个问题。开发者利用资源控制系统保证工程文件在同一时间内保持一致。运用SQL Server Management Studio和直接联机模式下BI Development Studio的操作员依靠运行服务确保两个人不会同时进行相互矛盾的操作。这两种工作机制分别存在于自己的群体中。然而，他们却无法知道另一个群体做出的改变。运行中的服务不了解资源控制系统，资源控制系统也不了解运行中的服务。工程文件不能总是比较匹配运行的数据库。下面是几个这种麻烦发生的例子：

◆开发人员通过将一个现存的Analysis Services数据库引入到项目中的方式来创建一个项目。然后操作人员运用SQL Server Management Studio删除了数据库中的一个Cube。当开发人员配置项目时，cube有恢复了。这会产生一条如图1所示的消息：

图1：BI Development Studio检测到自最后一次开发后数据库被改变了

我们注意到消息没有告诉开发人员哪个对象被改变了，仅仅告知不匹配的数据库版本。因为开发人员不知道改变了的对象是否重要，她或他能做的事情就是点击YES。结果cube就恢复了。

◆Analysis Services项目被保存在资源控制系统中。你在Analysis Services服务器中通过执行SQL Server 2005集成服务包中XMLA脚本创建了一个新的分区。

例如，日常的SQL代理工作可能运行此包来处理引入的数据文件。当一个新的月份到来，此包为本月创建了一个新的分区。然后，开发人员在资源控制下改变了项目并配置项目。所有通过SQL Agent job创建的当月分区将消失。

◆运行的服务器系统崩溃并且丢失了一个磁盘驱动器。操作员将数据库恢复成为三个月前的状态，并且重新处理此数据库。开发人员配置一些QA要求的紧急改动（在资源控制下）时使得应用程序暂停。操作员认为应用程序停止是因为重新恢复备份被破坏。他们将数据库恢复到四个月前的状态。这时开发人员看到产品中没有他做的改变。因此开发人员有一次的配置了项目….因此有一次的停止了应用程序….随后操作员又将数据库恢复成为五个月前的状态。（你可以想象这种情况。）

如何解决这个问题…

这些事件的各种组合都可能发生。这将产生一些问题：

1.如何检测这种问题的发生

2.如何解决这种问题

检测到问题通常很简单。即使一个诸如修改一个对象属性这样的微小改变也会导致图1显示的错误。我们注意到仅仅是开发者被告知脱机项目文件的版本不再有效。除非开发人员告诉操作人员，否则操作人员并不知道他们在线的修改影响到了开发人员的工作。如果开发人员没有通知操作员并且开发人员继续配置他们的项目，即使数据库被修改，操作员看到的现象将是他们的修改来回反复存在和消失。

真正的挑战是如何解决这个问题。不幸的是没有一个机制自动的同步运行的Analysis Services数据库和脱机的Analysis Services项目。唯一的方法通过如下几个步骤来实现：

1.重现将Analysis Services数据库引入到一个新项目中。

2.利用引入功能重新创建所有文件

3.利用资源控制系统迁出项目（以及他们的子文件）

4.将新文件还原为迁出文件

5.迁入新版本到资源控制系统。如果你能正确操作上述步骤，现在资源控制系统将包含所有事务的最新版本

6.配置新项目，以让数据库版本号匹配。

另外一种方法是比较新引入项目文件和迁入资源控制系统的当前文件。一旦你发现了区别，逐一修改每个对象和属性以达到文件的匹配。你有效的做到了Analysis Services数据库和资源控制系统的人工同步。这种方法容易出错并且对于检测出所有差异和同步所有属性没有保证。

在同步过程中，无论是人工操作还是替换整个文件，操作员都不能在对在线系统做任何修改。此时的任意修改在最后的配置前都将被覆盖。所有的开发人员现在都必须从资源控制系统得到最新版本，或者迁出整个项目来更新人们本地的文件拷贝。

不管怎么来说，这个方法包括很多移动复制工作，这便很容易出错。如果你将要进行如此段描述的混合工作，你需要制定详细的能够确保开发人员和操作员协调合作的指导方针。

共20页: 2 下一页

【内容导航】

原文：Project REAL分析服务技术探讨(2)