MicroStrategy 备份项目源测试记录

MicroStrategy 备份项目源测试记录

背景

MSTR在测试环境初步测试结束，但由于初次使用，仍然存在部分风险情况发生，因此查找各种容错机制，保证正式环境部署时如果出现错误，可以及时进行恢复。

项目源以及元数据库

1.元数据库

MicroStrategy的元数据是存储在关系型数据库中的一个预定义结构，而MicroStrategy定义了这个元数据结构。MicroStrategy所有定义的框架对象、报表对象、配置对象等重要配置信息都会存储在元数据库中，并且元数据库并不一定要与数据仓库连接的数据库类型相同。

元数据库类型一般默认为Microsoft Office Access，是微软旗下的数据库管理系统。目前我所负责项目使用的MSTR元数据库便是默认的access数据库，根据观察，access中数据库会以文件的形式保存在磁盘中，可以直接通过access客户端打开访问，access 数据库文件通常以mdb为后缀名，比较特殊，方便辨识。

定义后的ODBC数据源对应的access数据库文件可以通过ODBC Administrator找到，通常在32位ODBC Administrator。

2.项目源

项目源为MSTR的最高级对象，每一个项目源代表一个元数据连接，可以进行直连，也可以通过定义Intelligence Server进行访问连接，前者与后者分别被称作两层模式以及三层模式(服务器模式)。

通常一个项目源下可以包含多个项目，但多个项目公用同一套项目源的配置，包括数据库实例、用户组等一些配置。相对于项目源的备份，报表对象的备份相对简单，可以通过建包的方式进行导入导出，切换至不同的项目中。

备份机制

其实目前我所了解的备份机制也比较简单，由于元数据库无论通过那种模式连接，最终数据都会存在设定好的数据库中进行存储，因此备份机制从某种程度上讲可以等同于数据库的备份。将需要备份的项目源连接的源数据库直接进行备份，推测可以完成对整体项目源的备份。

目前思路:Access数据库直接对项目源对应的数据库文件进行备份完成后，需要恢复时，将项目源与元数据库之间的连接切断(关闭Intelligence Server/关闭相关组件等等)，直接将之前备份过的mdb文件覆盖到元数据库对应路径下的对应mdb文件，重新启动与元数据库的连接，更新框架，即可进行备份操作。

1st测试

1.备份项目源对应mdb文件。
2.备份后在项目源下随机打开一个项目，创建实体对象，数据仓库添加新的数据表。
3.完成后关闭项目源，关闭Developer端等相关组件。(此处失误并未停止Intelligence Server)。
4.确认项目对应的mdb修改时间已经更新，代表新建对象信息已经写入，将之前备份的mdb文件覆盖目前最新的mdb文件。

5.重新打开MicroStrategy，查看之间创建的新建对象是否存在。

由于第三步的失误，之前创建的测试对象仍然存在，且无法删除，推测时由于服务器依然启动存在缓存，但元数据库中已经无法找到对象相关的配置信息，所以对象无法删除，也不能被编辑。

6.由于失误，重启Intelligence Server，查看数据仓库以及对象，确认恢复至备份前的情景。

7.最终结果:出现实体被删除，更新框架报错，但无法查询到ID对应实体，删除测试项目重新部署。

2nd测试

整体步骤与之前相同，不同点在于本次测试中:

1.建包时添加安全筛选器配置，导入新项目后会生成筛选器中依赖的实体。

2.本次测试，在确认要备份版本后，首先关闭Developer等相关客户端，同时关闭Intelligence Server，然后再进行备份。

备份完成后打开Developer端进入项目，开始建立测试文件夹/报表/实体，完成后关闭Developer等相关客户端，同时关闭Intelligence Server，用备份的mdb直接覆盖掉目前现版本的mdb。

3.测试结果:暂未发现异常情况，更新框架无异常；报表运行查看在客户端以及web端均无异常。

3rd测试

本次测试重新创建测试专用项目源，基于Access数据库创建测试元数据库，两层模式直接连接，测试直接覆盖是否会存在影响。

1.创建之前先要存在全新的测试access数据库产生，access数据库目前使用感觉相对其他数据库较为简单，每一个数据库对应一个mdb文件。

2.创建元数据库需要通过MicroStrategy的config wizard进行创建，由于只是测试，使用直连的方式。

3.重复第二步的步骤。

4.最终结果:项目源成功还原，未发现明显异常。

后续

根据查阅的相关备份资料，确认备份项目源等同于备份元数据库，但其中可能存在细节调整目前并未发现，所以备份机制目前仅在测试环境进行，后续还需进行多次测试。