SQL Server 2008 R2，从一台计算机上把一个数据库复制到另一台计算机上，有人成功过没？

xxMix 2011-03-06 12:49:44
1.环境

机器1：Windows XP SP3
SQL Server 2008 R2
机器名：WPF-PC3
操作系统的管理员名称：SystemAdmin
SQL Server管理员名称：A3
（SQL Server管理员，是指，在SQL Server Management Studio 企业管理器 里的 【安全性】 -> 【登录名】 创建的。
身份验证方式为SQL Server身份验证，服务器角色为 sysadmin）

机器2：Windows Server 2003
SQL Server 2008 R2 (两台机器，都是同一个版本)
机器名：WPF-Server1
操作系统的管理员名称：SystemAdmin
SQL Server管理员名称：AS

2.需求
把WPF-PC3上的TestDB，复制到WPF-Server1 上去。

3.实验
3.1 WPF-PC3：本地 -> 本地，都用 【Windows身份验证】
在WPF-PC3上，通过企业管理器，对【TestDB】单机右键，从任务里选择【复制数据库】，然后，
【源机器】和【目标机器】，填的都是【WPF-PC3】，身份验证都选【Windows身份验证】，
复制方式是【使用 SQL 对象管理方法】，复制到目标数据库【TestDB_new】，然后开始执行，执行成功。

3.2 WPF-PC3：本地 -> 本地，都用 【SQl身份验证】
过程如上，不同点在于，身份验证都选【SQL身份验证】，填入WPF-PC3的数据库的管理员账号
【AS】以及密码，执行成功。

3.3 WPF-PC3 -> WPF-Server1，都用【Windows身份验证】。
执行失败。【详细错误信息】，见附录1。
【详细错误信息】 中的 【第一次出现的错误】：
InnerException-->用户 'NT AUTHORITY\ANONYMOUS LOGON' 登录失败。

3.3 WPF-PC3 【使用Windows身份验证】 -> WPF-Server1 【使用SQL身份验证】
执行失败。【详细错误信息】 以及 【详细错误信息】 中的【第一次出现的错误】，同 3.3

3.4 WPF-PC3 -> WPF-Server1 ，都用【SQL身份验证】
执行失败，但是，WPF-Server1成功建立了【TestDB】数据库，只是里面没有任何数据（表、存储过程等）。
【详细错误信息】，见附录2。
【详细错误信息】 中的 【第一次出现的错误】：
无法对 主体 'WPF-PC3\SystemAdmin' 执行 查找，因为它不存在，或者您没有所需的权限。

以上全是 WPF-PC3 本地实验，以及从 WPF-PC3 到 WPF-Server1 的实验。
WPF-Server1的本地实验，以及从 WPF-Server1 到 WPF-PC3 的实验，也做了，结论和上面一样。

求原因~ 以及解决方法~~

附录见下帖
...全文
1120 8 打赏 收藏 转发到动态 举报
写回复
用AI写文章
8 条回复
切换为时间正序
请发表友善的回复…
发表回复
xxMix 2011-03-06
  • 打赏
  • 举报
 回复
由于论坛里，帖子字数有限制，所以我把错误信息附录发到博客里，麻烦移步到这里：
http://blog.csdn.net/xxMix/archive/2011/03/06/6226806.aspx
dawugui 2011-03-06
  • 打赏
  • 举报
 回复
[Quote=引用 4 楼 fredrickhu 的回复:]
这样其实很麻烦 为什么不用备份了再还原 或者分离了再附加呢
[/Quote]我非常同意您老的观点.
东那个升 2011-03-06
  • 打赏
  • 举报
 回复
登陆用户的问题吧。
为什么不直接还原备份。。。
fcuandy 2011-03-06
  • 打赏
  • 举报
 回复
在服务器间复制对象和数据时先尝试不要复制数据库登陆， 看能否成功。
xxMix 2011-03-06
  • 打赏
  • 举报
 回复
[Quote=引用 4 楼 fredrickhu 的回复:]
这样其实很麻烦 为什么不用备份了再还原 或者分离了再附加呢
[/Quote]

我觉得，在本机上复制一个不在使用中的数据库，用这个方法，可以最短时间内搞定。

然而，在本机对本机的试验中，已经完成，那么，为什么本机对其它机器的复制，不能用这个方案，而要去用别的更繁杂的方法呢？
--小F-- 2011-03-06
  • 打赏
  • 举报
 回复
这样其实很麻烦 为什么不用备份了再还原 或者分离了再附加呢
xxMix 2011-03-06
  • 打赏
  • 举报
 回复
有些图片太大，论坛里显示不下，可以右键图片，选属性，把【地址URL】复制后，粘贴到浏览器地址里，再打开，以查看全图。
xxMix 2011-03-06
  • 打赏
  • 举报
 回复
操作过程图：

PIC1/16




PIC2/16




PIC3/16




PIC4/16




PIC5/16




PIC6/16




PIC7/16




PIC8/16




PIC9/16



PIC10/16




PIC11/16


PIC12/16




PIC13/16




PIC14/16




PIC15/16




PIC16/16
MSSQL2008复制服务配置方法及心得
曾经使用过Sybase SQL Anywhere 11数据同步采用内置插件MobiLink居于日志事务流形式的通讯，优点速度快、准确、夸平台，网络开销极低情况下保证通讯顺畅不丢包。由于工作原因开始接触MSSQL，有人说MSSQL没有此功能、类似的功能不好用等诸多说法，也很好奇全国某些知名软件开发上采用MSSQL，但数据库之间通讯还采用自己写通讯程序完成数据库之间数据交换，效率低、操作繁琐、数据传输重复、漏传、致命性错误、人工干预滞后等诸多问题。我想那么大一个微软公司不可能没有办法解决此问题，最近几天本开始研究了一下MSSQL复制服务，通过发布和订阅达到数据通讯或者备份目的，首先我点评一下MSSQL复制服务，整体来说感觉还不错，缺点是不启动管理器没法监控发布和订阅情况（也许本人不够专业，没有发现）。复制服务需要发布、分发、订阅三部分组成，发布与分发可以集成在一起，如果订阅端较多建议独立分发。 测试环境Windows2008ServerR2+MSSQL2008R2SP3，两台计算机，发布与分发一体，然后一个订阅端。 1、 发布与分发服务器计算机名：Publish_Server IP地址：192.168.20.1 2、 订阅服务器计算机名：Subscribe_Server IP地址：192.168.20.2 由于没有域控环境，首先在两台机器的hosts文件的尾部加入： 192.168.20.1 Publish_Server 192.168.20.2 Subscribe_Server 加入的原因是没有域控和DNS服务器，通过机器名解析能快速准确的解析到IP地址只有在hosts文件中做文章，我想这个你应该懂的！ 如何安装MSSQL2008R2我就不在说了自己到百度搜索，首先关闭两台机器本机自带防火墙或者把1433、21端口加入防火墙策略，1433端口不用说了吧！21是用于FTP第一次分发快照的端口。 SQL2008提供的发布类型有4种：（我先照搬微软的说明） 1、 快照发布：发布服务器按预定的时间间隔向订阅服务器发送已发布的数据库快照。 2、 事务发布：在订阅服务器收到已发布数据的初始快照后，发布服务器将事务流式 传输到订阅服务器。 3、 具有可更新订阅的事务发布：在 SQL Server 订阅服务器收到已发布数据的初始快照后，发布服务器将事务流式传输到订阅服务器。来自订阅服务器的事务被应用于发布服务器。 4、 合并发布：在订阅服务器收到已发布数据的初始快照后，发布服务器和订阅服务器可以独立更新已发布数据。更改会定期合并。Microsoft SQL Server Compact Edition 只能订阅合并发布。 （1）快照发布，这种每次订阅服务器都去下载完整快照这效率低，对网络要求也高，个人觉得不可取。（2）事务发布，只要订阅服务器收到初始快照后，订阅服务器将用事务流的方式到发布上取数据，速度相当快网络和机器性能好的情况毫秒级的响应，这种模式数据是单向的，发布服务器到订阅服务器，订阅服务器端不能对数据进行修改，即使进行了修改是也暂时的，下次发布服务器对应数据做了更新后订阅服务器数据将被同步。（3）具有可更新订阅的事务发布，这个研究了半天没有成功，还要在订阅服务器上把分发服务器作为链接服务器，本人愚昧没有实验成功。（4）合并发布，数据在发布和订阅端都可以进行修改，而且可以自动合并。根据同场景本人推荐：事务发布和合并发布，记住它们最大的区别就是事务发布是数据单向传送、合并发布是数据双向传送。 注意任何时候MSSQL叫你输入服务器名称都要用实例名不能输入IP地址（一台机器上只安装了一个实例的话实例名就是计算机名，这下知道hosts文件的重要性了吧，谁叫我们不在域控制器下呢！其实在微软操作系统中计算机名比IP高一级，但我们在使用中往往把IP地址看得比计算机更重要，这就是没有域控制器的原因。为了计算机名能快速、准确的解析到就乖乖的去hosts文件中添加吧！）
ZUCK多用户微信商城分销直销平台.zip
一、郑重申明 1、本系统系采用DTcms4.0框架开发，所有功能未抄袭任何微信系统，全部为自主开发。 2、本系统专业为公众号商城系统量身打造，系统自带三级分销，以及商城直销两种模式。 3、系统截图中有运营公众号商户平台的下单截图，确保系统的从商城到商品从下单到支付都是无bug的。 4、任何购买者享受升级服务，售后支持。 二、源码特点 1、微信商城公众平台开发，微商城所有功能进行完整开发。 2、多用户：可同时进行多公众号的管理和配置，每个公众号可配置5个子账号。 3、直接性：购买者可直接购买细微修改即是成品的平台商品。 4、开发语言:Asp.Net,C# ,Webform，数据库SqlServer2008R2 三、功能介绍 1、菜单回复：关注时回复、文本回复、图文回复、客服消息。 2、自定义菜单：公众号自定义菜单设置 。 3、客户管理：获取关注公众号的账户信息进行管理。 4、二维码链式推广：对于采用分销模板的商户，可以设置用户的二维码分销推广功能。 5、微商城：商城模板配置、产品分类管理、商品管理、商品录入、客户管理、订单管理，订单打印，运单打印。 6、支付方式：微信支付V3.0。 7、商城模板：分销模板、直销模板 8、后台菜单：后台导航菜单管理 9、大管理端：可在后台看见所有商户以及商户子公众号的信息，可开启计费运维，或者单为某个商户开账户也行。 10、BI智能图标分析。 四、注意事项 开发环境：VS2012、SQLSERVER2008R2 发布环境：WindowsServer2003、.NetFramework4.0+ 、IIS6.0 五、附加说明 微信商城的功能是齐全且稳定的，大家可能会问为什么没有营销工具？ 首先出于一个最直接的考虑就是，不想把一个好的东西弄的乱七八糟弄上去给人感觉是大而全的，但是实践证明大而全的东西都是不可用的，这是程序员给自己偷懒找的借口。本系统页面清爽、微信端页面也是清爽简洁适用于各种类型的商品风格。商城是正式运营确认无误的，对于营销工具诸如：大转盘、刮刮卡、投票.....等等等等，这些都是实践已淘汰的东西。大伙儿可以自主开发营销工具，比如摇一摇、0元购、等新型营销，系统我可以向大家保证，可以完美集成进去。针对自身不同的业务需求订制需要的才是最好的！
成品网站源码网站源码后台
源码描述： 一、源码特点 1、三层架构MVC通用网站CMS系统源码，网站前端使用js、jqury、Html5、bootstrap响应式布局；系统后台采用ASP.NET MVC框架三层架构MODEL数据库增删改查，批量操作，bootstrap、Ajax、js、jquery、数据统计，加密与解密，时间控件，富文本内容编辑器。 二、菜单功能， 1、 网站后台：主要包括登陆、主页管理、分类管理、文章管理、评论管理、标签管理、图片管理、用户管理添加的功能、删除、查询的功能。单页面实现bootstrap模态框ajax数据操作，使用SqlBulkCopy批量添加，js标签增删改查，泛型，Razor语法，数据库增删改查，批量操作，bootstrap、Ajax、js、jquery、数据统计，加密与解密，时间控件，富文本内容编辑器， 后面会加入数据统计与分析图表，包括菜单分析，文章分析，用户分析等便于更新和完善网站内容。 2、网站前台：主要包括首页，内容页，分类页，搜索页，主要实现文章摘要处理和razor，数据显示HTML处理，还有js jquery html5布局。 3.系统结构清晰易于更新与维护开发 三、注意事项 1、开发环境为Visual Studio 2013，数据库为SqlServer2008R2，使用.net 4.5开发。
基于微软Azure、.NET Core和Docker的博客系统.zip
首先简要介绍一下目前的站点功能吧。右图就是本站的主页效果，我做得很简洁，没有用太多花哨的图片，也没有用走马灯。明眼人一看就知道这是基于ASP.NET MVC而开发的Web应用程序，使用了Bootstrap。不错，基本答对！需要强调的是，这个博客站点以及后端的RESTful服务，全部都是基于ASP.NET Core完成的，.NET Core运行时版本为1.1.0，运行在Docker容器中。哎，说着说着又到技术上了，功能还没介绍完呢。说到功能，目前功能很简单：主页列出了我自己原创或者翻译的所有文章，读者可以注册用户帐号，注册用户可以发表评论，也可以在用户管理页面中更改自己的昵称。好了，目前功能就这么多，别看功能少，我可是前前后后陆陆续续花了2个月的时间，才做到目前这个样子。当然，我会继续更新这个站点，让它的功能变得更加完善。提到ASP.NET Core，有没有吊起你的技术胃口呢？不用着急，接下来我就介绍一下整个站点中各部分的技术选型，看完后，或许你会知道为什么我花了2个月的业余时间，才整出来这么个简单的玩意儿。站点技术介绍整体架构整个网站所采用的所有基础设施全部运行在微软云（Windows Azure）中，使用了部分托管资源，以及一些非托管的Azure VM。大致情况如下：图片存储服务：由Azure Blob Storage Service托管数据库系统：由Azure SQL Database托管（未启用Geo-Replication，因为没钱）邮件服务：由Azure SendGrid Account托管（Pricing Tier为F1，每月可以免费发送25000封邮件）应用服务器：基于Azure构建的Ubuntu 16.04.1 LTS虚拟机，运行了两个Docker容器：blog-web和blog-service，分别托管前端Web站点和后端RESTful服务。后端RESTful API服务没有做任何认证和授权，Web站点通过内部子网访问RESTful API服务，Docker容器运行在非托管环境中持续集成系统：Jenkins，基于Azure构建的Windows Server 2012 R2一台（Master），和一台Ubuntu 16.04.1 LTS（Slave）。站点的前端和后端都在后者（Ubuntu）中完成编译、打包以及Docker镜像的发布，实现了一步到位的部署方式代码库：Github有人会问：为什么使用了非托管的Azure VM环境运行应用系统？我也考虑过这个问题，理论上讲，基于云的系统架构最好选用托管的PaaS服务，这样不仅可以得到纯天然的高可用性（包括灾备，比如AWS的跨AZ部署，某些服务跨区域的可用性，以及负载均衡），而且还可以得到专业的技术支持。只有当存在老系统向云迁移的需求，并需要迎合老系统的特定运行环境要求时，才考虑使用IaaS服务。虽然虚拟机等这些资源是由Azure负责创建并运行的，在这一层面Azure可以保证虚机的可用性，但虚机内部运行的任何程序的状态，以及所使用的数据，Azure等云服务是无从得知的，对这部分东西的监控也会变得很麻烦。出于安全考虑，通常云服务供应商是不会，也不应该获得类似虚机内部的客户程序的运行数据的，使用虚拟机服务所产生的程序运行风险，客户需要自己承担。这也就是著名的责任共担原则。看起来用虚拟机运行应用不是太靠谱嘛，然而我却选择这么使用了。有几个原因：为何不使用Azure Web App？一方面Jenkins做自动化部署，直接把编译好的应用推送到Azure Web App中好像不是太顺手，要写一些PowerShell的代码，可是我的编译系统是Linux，不过现在已经有Linux版的PowerShell了，而且Azure SDK Command Line Interface也有Linux版，所以这个理由有点牵强，更合理的解释是：劳资不会！另一方面，我没有在服务端做认证和授权，仅通过子网向外界提供服务，所以我希望我的Web App也运行在子网内部，然后向外暴露80端口供外界访问。这样一来，Azure Web App又如何部署到我自己的子网内？这是一个技术问题，我相信一定有解决方案，但是我也没太多时间和精力去细究如何实现，自己的第一反应也无非是将前后端全部部署在Azure Web App中，然后打开后端的认证机制。但这样做又要花一些额外的工夫。好吧，还是这个理由：劳资不会为何不使用Azure Container Service？Azure Container Service会在你指定的Resource Group（资源组）中创建一整套网络部署，包括好几台虚拟机、公网IP、两个负载均衡器等等，我想你一定知道我为什么没有选择Azure Container Service了，原因就是：劳资没钱理由够充分吧？微软Windows Azure提供的这些服务都很赞，我没选不是说它们不好用，而是出于自己的实际情况考虑：某些服务的学习成本经济成本暂时没必要做到99.99999%的高可用率即使应用挂了，恢复的成本很小：数据完全不需要恢复，托管的SQL Database、Blob Storage会保证我的数据不丢失，应用程序恢复也很简单：重新运行Docker容器就完事儿OK，从整体架构上看，我的选择即是如此而已，这样的选择当然不一定完全正确，但我觉得至少合适，仅供参考。下面附上本站点的整体架构图。作几点注解：三台VM位于同一个Virtual Network的subnet中，每台VM的虚拟网卡上都套有独立的Network Security Group（NSG），在NSG上设置了Inbound/Outbound Endpoints，严格限制了端口访问的IP地址。三台VM之间使用subnet IP地址访问Windows Server 2012 VM宿主了Jenkins Master，以及Seq日志服务。它向公网暴露8080端口和5342端口，分别用于访问Jenkins服务和Seq管理界面第一台Ubuntu VM运行了Jenkins Slave，它不向公网暴露任何端口，仅向Jenkins Master机器暴露22端口，用于Jenkins Slave Agent的执行调度第二台Ubuntu VM运行了博客系统的两个Docker容器：前端应用程序blog-web和后端RESTful API服务程序blog-service。web通过子网IP地址访问service，VM仅向公网暴露80端口，后台service无法从公网访问两个Docker容器所运行的应用（blog-web和blog-service）都可以访问托管的Azure SQL database、Azure Storage blob和SendGrid Account服务整个部署的拓扑结构有可能不太合理，比如没有做负载均衡，没有使用托管的应用宿主服务（比如Azure Web App、Container Service等），没有使用Scaleset。因为目前没必要而且没钱更多说明，详见作者的博客：http://daxnet.me/blogposts/post/221 标签：daxnet
微信营销系统（第三方微信平台）之微分销模块拓展 MicroDistributionModuleWeChat.rar
微信营销系统（第三方微信平台）之微分销模块拓展 源码描述： 一、源码介绍 微分销系统，让所有参与分享和推广的人都能成为受益者，让新会员、老会员、潜客、信息安全人员成为一个共同体，形成高粘性的闭环。 微分销，是基于微信公众平台上的二级分销商城，是伴随着微信营销的火热而兴起的一种网络营销方式。 基于“微信营销系统（第三方微信平台）”平台的拓展http://www.51aspx.com/code/codename/62255 二、主要功能 微分销一期实现的功能（现阶段） 4.1、PC后端 1、增加渠道管理； 2、增加返佣清单； 3、修改订单详情，添加返佣详情； 4、添加查看下级功能； 5、添加审核渠道人员入口； 6、后台提供改价功能（解决部分地区有优惠的场景） 7、解决返佣是按照特点价格（例如扣除评测中心部分） 8、微主页扩展“我的分销Url” {{#DCCenterUrl}}标签 4.2、微信端： 1、增加“我的分销”页面：实现分销相关的信息显示和入口（我的返佣、我的下级、推广海报、我的推广码、） 2、增加“我的返佣”页面； 3、增加“我的下级”页面； 三、注意事项 1、开发环境为Visual Studio 2015，数据库为SqlServer2008R2，使用.net 4.5开发。
疑难问题

22,210

社区成员

121,726

社区内容

发帖
与我相关
我的任务
社区描述
MS-SQL Server 疑难问题
社区管理员
  • 疑难问题社区
  • 尘觉
加入社区
  • 近7日
  • 近30日
  • 至今

加载中

查看更多榜单
社区公告
暂无公告

试试用AI创作助手写篇文章吧

+ 用AI写文章