QC的迁移 .

pcxty

QC的迁移
  
方法一：（实际迁移过程的个人总结）

目的：QC-A上面所有项目备份到QC-B上面能用。

一：对QC-A数据库进行备份，停止数据库服务，将数据库中的文件直接拷贝出来，这样在恢复时直接在数据库中附加上去就行了。

二：备份QC-A安装目录下的repository文件夹，复制一份就可以了。

三：在QC-B上面安装好SQL QC程序。

四：将QC-A上面数据库全部附加或还原到QC-B上面去，里面有qcsiteadmin_db和qcsiteadmin_db库。注意：如果恢复已有项目的QC，并且不同项目设置了不同用户，先附加或还原项目库再还原qcsiteadmin_db和qcsiteadmin_db库。

五：将第一步备份的repository文件覆盖QC-B安装路径下的repository文件夹。

六：用admin帐号和QC-A的管理密码登录QC-B的管理界面，将所有的项目激活（还原过来的项目都处于非激活状态），附加的直接可以用。

七：在QC-B的管理平台里面重新设置repository文件库存放的地址，将所有项目的数据库连接地址改成QC-B的数据库。然后重启QC服务。

八：重启QC服务后，连接时可能会有无法连接的错误，是由于迁移时数据库登录名丢失，

           可运行下面的代码，系统会列出当前数据库的孤立用户数。

             exec  sp_change_users_login 'report'

            我们只需要选择当前数据库为还原的库，然后运行

             exec  sp_change_users_login 'update_one','TD','TD'   来添加登录名。

九：连接时会可能出现无法连接部分表：解决很简单，就是察看TD登录用户是否具有dba的权限或者系统管理的权限，没有的话添加系统管理权限，因为QC使用TD用户管理。

遇到问题一：

从九中添加了DBA的权限还是无法连接表，有时启动会报下面的错误
            “t Projects Properties;
               Failed to get projects properties;
               Failed to save projects properties;
               Cannot build directory item for key '[项目_2011年项目_db@jdbc:mercury:sqlserver://127.0.0.1:1433(td)]' in TD Tables Struct Dir;
               [Mercury][SQLServer JDBC Driver][SQLServer]对象名 'SEQUENCES' 无效。;
               Stack Trace:
               java.sql.SQLException: [Mercury][SQLServer JDBC Driver][SQLServer]对象名 'SEQUENCES' 无效。”

对象“****”无效，在实践中对比其他能正常启动的项目发现是所有者错误，那么就需要修改项目表的所有者。
       批量修改：
            EXEC sp_MSforeachtable 'exec sp_changeobjectowner ''?'',''dbo'' '
       单个修改：
            exec sp_changeobjectowner '要改的表名','dbo'
       只有所有者才能更改表的所有者

有些服务器:   消息   15001，级别   16，状态   1，过程   sp_changeobjectowner，行38 对象   'user'   不存在或不是对此操作有效的对象。   
执行
exec sp_changeobjectowner '表所有者.要改的表名','dbo'

修改所有者后就能正常启动项目了。

到这里从QC-A到QC-B的过程就算完成，可以用QC-A的帐号合和密码登录到QC-B上面去。



方法二：网上收集资料

下面说说我的备份方案，可能不是最好的，但是一定可行的，已经验证过。备份很简单但是恢复比较麻烦。

目的：QC-A上面所有项目备份到QC-B上面能用。

一：对QC-A数据库进行备份，备份所有的库。

二：备份QC-A安装目录下的repository文件夹，复制一份就可以了。

三：在QC-B上面安装好SQL QC程序。这里要注意，QC-B的程序安装路径一定要和QC-A一模一样。

四：在QC-B上面安装好QC程序的时候，数据库里面已经有了2个库,qcsiteadmin_db和qcsiteadmin_db库，将这个2个库重命名。

五：将第一步备份的repository文件覆盖QC-B安装路径下的repository文件夹。

六：将QC-A上面数据库全部还原到QC-B上面去，里面有qcsiteadmin_db和qcsiteadmin_db库。

七：用admin帐号和QC-A的管理密码登录QC-B的管理界面，将所有的项目激活（还原过来的项目都处于非激活状态）

八：在QC-B的管理平台里面将所有项目的数据库连接地址改成QC-B的数据库。

到这里从QC-A到QC-B的过程就算完成，可以用QC-A的帐号合和密码登录到QC-B上面去。

或者你有更好的备份方法，如果不介意的话，请留言告知！

十分感谢！





数据库使用备份还原造成dbo登录名丢失解决法

在使用数据库的过程中，经常会遇到数据库迁移或者数据迁移的问题，或者有突然的数据库损坏，这时需要从数据库的备份中直接恢复。但是，此时会出现问题，这里说明几种常见问题的解决方法。

一、孤立用户的问题

比如，以前的数据库的很多表是用户test建立的，但是当我们恢复数据库后，test用户此时就成了孤立用户，没有与之对应的登陆用户名，哪怕你建立了一个test登录用户名，而且是以前的用户密码，用该用户登录后同样没办法操作以前属于test的用户表。

这个问题有两种办法解决。

先说解决的前提条件。

首先，要用备份文件还原数据库，我们这里的数据库名为testdb，里面有属于用户test的用户表。这个很容易了操作了，不多讲了，在企业管理器中很方便可以恢复。恢复后，就产生了孤立用户test。

然后，用sa用户或者具有DBA权限的用户登录，创建一个test数据库登录用户，密码随便设置了，也可以和以前的保持一致。我们用它来对应孤立的test用户。

下面就有两种操作方法了，第一种就是改变对象的属主，第二种就是使登录用户和数据库的孤立用户对应起来。

方法一：修改对象属主

就是将原本属于数据库用户test的用户表，修改为属于dbo的用户表；然后修改test登录用户的数据库为testdb,就可以直接使用test登录用户登录后对该数据库进行操作了。

使用的存储过程

sp_changeobjectowner [ @objname = ] 'object' , [ @newowner = ] 'owner'

直接在查询分析中选中你要操作的数据库运行

EXEC   sp_changedbowner   'sa'      停止数据库后重新启动后 数据库德所有者就是sa用户了！ 同时可以解决dbo用户无登录名的问题！

参数说明：

[ @objname = ] 'object'

当前数据库中现有表、视图、用户定义函数或存储过程的名称。object 是 nvarchar(776)，没有默认值。如果架构及其所有者具有相同的名称，则 object 可由现有对象所有者限定，格式为 existing_owner.object。



[ @newowner=] 'owner '

将成为对象的新所有者的安全帐户的名称。owner 的数据类型为 sysname，没有默认值。owner 必须是可访问当前数据库的有效数据库用户、服务器角色、Microsoft Windows 登录名或 Windows 组。如果新所有者是没有对应数据库级主体的 Windows 用户或

Windows 组，则将创建数据库用户。

实例：

以下示例将 authors 表的所有者更改为

dbo。

EXEC sp_changeobjectowner 'authors', 'dbo';

GO

这个方法有个最大的缺点就是，当表的数量非常多，而且还有存储过程或者触发器之类的修改起来会非常麻烦，需要一个一个修改，所以，不提倡使用。现在网上有一个批量修改的存储过程，大家可以找一下，这里就不说了，而是教大家一个更简单的。



方法二：使登录用户和数据库的孤立用户对应起来

其实我们建立了同样名称的数据库登录用户后，数据库中的表我们照样不能使用时因为sid的不同，就是系统登录表和数据库用户表中的用户名相同，单是sid字段，数据库中的还是以前旧系统的sid值，所以我们就要把它对应成我们新建的，数据库靠sid来识别用户。

这里可以使用存储过程sp_change_users_login。它有三种动作，分别是report，update_one和auto_fix。

运行下面的代码，系统会列出当前数据库的孤立用户数。

exec  sp_change_users_login 'report'



我们只需要选择当前数据库为testdb，然后运行

exec  sp_change_users_login 'update_one','TD','TD'



系统就会提示修复了一个孤立用户。

如果没有建立TD的登录用户，还可以用

exec sp_change_users_login 'Auto_Fix', 'test', NULL, 'testpassword'

来创建一个登录用户名为TD，密码为testpassword的用户与之对应。



好了，到这里通常情况下，数据库对象得到访问问题已经解决了。如果有多个数据库中有同一个用户的数据表，只需要选择不同的数据库，执行update_one的那个就行了。

二、对象名 ‘xxxx’ 无效的问题

这里可能会有人遇到对象名 ‘xxxx’无效的问题。系统表却不会产生这个问题，而用户表还要加上用户名，然后是表明才能访问，比如select * from author,会说对象名 author 无效，而用select * from test.author就可以访问，这个是用户首选身份的问题。

解决很简单，就是察看TD登录用户是否具有dba的权限或者系统管理的权限，没有的话添加系统管理权限，因为QC使用TD用户管理

（如果是其他数据库还原的话有就去掉就行了，因为如果用户有dba身份，那么它登陆后的默认表空间是dbo的系统表空间，所以去掉了之后，就会以正常的test表空间访问数据表了。
）