C# 分离数据库

sp_detach_db 需要Exclusive Access才能成功detach一个数据库。

你现在遇到的问题是程序拿不到Exclusive Access（独占该数据库）。

你不应该在程序中调用这个sp_detach_db。因为在真实环境中你会遇到很多各种各样的原因拿不到Exclusive Access，或者即使拿到Exclusive Access 还有其它很多原因是sp_detach_db执行不下去。

sp_detach_db 是给DBA用的管理命令。DBA会根据当时环境采取各种措施确保所有前提条件成立。然后手动调用sp_detach_db 分离数据库。

所以你面临的错误不是程序层面能解决的，应该是设计或架构的问题。

下面是一些

参考资料：

A database cannot be detached if any of the following are true:

The database is currently in use For more information, see "Obtaining Exclusive Access," later in this topic

If replicated, the database is published

Before you can detach the database, you must disable publishing by running sp_replicationdboption

Note:

If you cannot use sp_replicationdboption, you can remove replication by running sp_removedbreplication

A database snapshot exists on the database

Before you can detach the database, you must drop all of its snapshots For more information, see How to: Drop a Database Snapshot (Transact-SQL)

Note:

A database snapshot cannot be detached or attached

The database is being mirrored

The database cannot be detached until the database mirroring session is terminated For more information, see Removing Database Mirroring

The database is suspect

In SQL Server 2005, you must put a suspect database into emergency mode before you can detach the database For more information about how to put a database into emergency mode, see ALTER DATABASE (Transact-SQL)

The database is a system database

对于用存储过程来分离数据库，如果发现无法终止用户链接，可以使用ALTER DATABASE命令，并利用一个能够中断已存在链接的终止选项来把数据库设置为SINGLE_USER模式，设置为SIGLE_USER代码如下：

ALTER DATABASE [DatabaseName] SET  SINGLE_USER WITH ROLLBACK IMMEDIATE

下面是分离数据库的CMD命令

EXEC sp_detach_db DatabaseName

一旦一个数据库分离成功，从SQL Server角度来看和删除这个数据库没有什么区别。

你是想用dos窗口写命令处理吧，直接打开cmd

分离数据库

osql -S localhost -E -d "master" -Q "exec sp_detach_db mydb"

附加数据库

osql -S localhost -E -d "master" -Q "exec sp_attach_db mydb,'D:\data\mydb_datamdf' “

--后面是路径

我测试是可以的，望楼主采纳

默认安装的话,新建的应为C:\Program

Files\Microsoft

SQL

Server\MSSQL\Data\

2个文件以后不管放到哪里,可以附回去

如果ldf太大,且不想要这些个日志时,先确定你分离正常,附加的时候,可以先把ldf放到别处,这样如果附加成功的话,ldf会重建,原先那个ldf就可以不要了

ldf减肥的方法最好还是用缩,或先备份后还原

1。分离数据库是为了，将数据库可以移动到另一个位置，例如拷到你的u盘上或者你换了另一台电脑，如果没有分离，数据库文件是不允许进行复制，剪贴的

2。并不会对数据库产生影响，你可以再将数据库进行附加 *** 作· ··

3。分离后的数据库仍是。mdf。ldf文件，只不过是可以将分离后的数据库进行复制、粘贴 *** 作而已

分离后的数据库仍在你一开始建数据库的位置，并没有改变

这只是我自己的实际经验，呵呵，希望对你有帮助···

如果您数据库系统安装在系统盘（比如C盘），由于C盘容易受病毒侵害，您也许希望您的数据存放在非系统盘（比如D盘），要做的这点很简单，您并不需要重装数据库，只要把数据“分离”，然后将相关文件复制到D盘的某个目录，接着“附加”数据库即可。

SQL Server 2000允许分离数据库的数据和事务日志文件，然后将其重新附加到同一台或另一台服务器上。分离数据库将从SQL Server 删除数据库，但是保持在组成该数据库的数据和事务日志文件中的数据库完好无损。然后这些数据和事务日志文件可以用来将数据库附加到任何SQL Server实例上，这使数据库的使用状态与它分离时的状态完全相同。

数据库分离和附加其实很简单，您即使是初次接触数据库，做起来也很容易。

一、分离数据库

1、点击“程序》Microsoft SQL Server》企业管理》”，打开企业管理器

2、展开服务器组，然后展开服务器，选中要分离的数据库

3、点击鼠标右键“所有任务》分离数据库”，出现如下窗口

4、点击确定，该选定的数据库就被分离。

应注意，只有“使用本数据库的连接”数为0时，该数据库才能分离。所以分离数据库时尽量断开所有对要分离数据库 *** 作的连接，如果还有连接数据库的程序，会出现数据库的连接状态窗口，显示正在连接此数据库的机器以及名称，点击清除按钮将从服务器强制断开现有的连接。

二、附加数据库

1、复制移动数据库文件

在附加数据库之前，您必须将与数据库关联的 MDF（主数据文件）LDF（事务日志文件） 这两个文件复制到目标服务器上，或是同一服务器的不同文件目录下。这两个文件一般位于C：\Program Files\Microsoft SQL Server\MSSQL\Data目录下。

2、点击“程序》Microsoft SQL Server》企业管理》”，打开企业管理器

3、展开服务器组，然后展开服务器

4、右击"数据库"，然后选择“所有任务》附加数据库”，d出窗口

5、输入要附加的数据库的MDF名称。如果不确定文件位于何处，单击浏览（""）搜索。若要确保指定的 MDF 文件正确，请单击"验证"。在"附加为"框内，输入数据库的名称。数据库名称不能与任何现有数据库名称相同。指定数据库的所有者

6、单击"确定"按钮。新附加的数据库的数据库节点即创建在"数据库"文件夹中。

当我们的数据库压力主键变大的时候，我们会尝试增加一些从节点来分摊主节点的查询压力。而一般来说，我们是用一主多从的结构来作为读写分离的基本结构。

而一般来说我们有两种常用的方法来实现读且分离架构：

客户端直接分离

这种方式是由客户端，或者我们的微服务直接进行数据库的读写选择。将读库选择路由到主库上进行，将查询路由到从主库上进行。

这种方式的优点在于因为是直连所以性能比较高，但是需要由业务团队了解数据库的实例细节，当数据库做调整的时候就需要业务侧同步改造。

使用数据中间件代理

这种方式是由一层代理层对数据的读写做分发，业务层将所有的请求都通过代理来实现。

这种方式的优点在于对于业务层不需要感知到数据库的存在，但问题在于数据中间件的性能要求较高，还需要专人来进行优化和维护，整体架构较为复杂。

但是我们发现，尽管这两种方式各有优劣。但核心都是通过数据的写入、查询请求的路由而实现的，那么这就会引发标题的问题：

主备同步存在延迟，所以在延迟时间内对插入的内容进行查询则无法查询到最新提交的事务。

那么如何保证主从一致性的问题，其实就变成了如何处理主从延迟的问题。

根据项目的大小，团队的规模以及主机的部署模式。我们处理问题的方法也有很多种。

最简单强硬的就是强制读主库。

一般情况下我们在不同的查询中会有不同程度的一致性要求。我们可以将需要保证数据一致性的请求配置强制查询主库，而对于无强依赖的查询请求仍然查询备库。

尽管这个方案不是很优雅，但是是最简单实现的方法，并且在Spring等框架的支持下一般只需要加一个注解就能实现。但这个方法的问题也是显而易见的，如果存在大量的强一致性要求的查询语句，则相当于没有进行读写分离与扩展。那么这种方法就会导致系统在数据库层面没有有效的扩展手段了。

由于问题产生的来源是主从延迟，所以在下一次查询的时候进行一段时间的等待以弥补这种延迟即可。

所以在进行主库的数据插入之后，让数据库数据连接或者对应的执行线程等待一段时间后返回。通过等待时间来消化掉主从备份的延迟时间。但是这个方法也有一些问题比如：这个等待时间一般是固定的，即便主从已经无延迟了也会继续等待到时间结束；如果在服务高峰时期，有可能数据在等待时间结束后仍然没有完成同步则仍然会存在一致性问题。

但这种方法优雅的地方是可以配合业务来进行实现，举例来说当用户下单之后，通过下单送卷或者下单抽奖的方式从前端拖住用户，从而当用户在一次连续 *** 作中再次查询自己订单的时候中间必然会间隔一定时间，也就让需要再次查询数据的时候保证了数据的一致性。

上述两种方案看起来可能不那么“技术”，感觉有点投机取巧。那么下面咱们可以分两种情况来讨论用更高技术的方法如何实现一致性。

对于主从复制来说，是当主库完成一个事务后，通知给从库，当从库接受到后，则主库完成返回客户端。所以当主库完成事务后，仅能确保从库已经接受到了，但是不能保证从库执行完成，也就是导致了主从备份延迟。

但是从库执行数据是有进度的，而这个进度是可以通过show slave status语句中的seconds_behind_master来进行描述，这个参数描述从库落后了主库数据多少秒，当这个参数为0时，我们可以认为从库和主库已经基本上没有延迟了，那么这时候就可以查询请求。

但seconds_behind_master是秒级的，所以只能大概地判断，由于精度较低，所以还是可能出现不一致的情况。

如果要求精准执行的话，我们可以比较同步文件的执行记录，具体来说是：

所以当Relay_Master_Log_File和Exec_Master_Log_Pos和其一致的时候，就说明从库的已执行数据已经追上主库了，那么这时就可以说保证了主从一致性了

但是比较同步文件的执行记录方法的问题在于，如果当前的这个事务的binlog尚未传入到从库，即Master_Log_File和Read_Master_Log_Pos未更新，也就无法保证从库已经包含最新的主库事务了。

而为了保证在一主一备的情况下，从库里一定接受到数据了，也就是Master_Log_File和Read_Master_Log_Pos中的数据是和主库一致的，我们可以开启semi-sync replication半同步复制。

半同步复制的原理是在主库提交事务前先将binlog发送给从库，然后当从库接受后返回一个应答，主库只有在接受到这个应答之后才返回事务执行完成。这样就可以保证从库的Master_Log_File和Read_Master_Log_Pos与主库是一致的，从而解决了主从一致的问题。

半同步复制可以解决一主一备的情况，但是当一主多备的时候，只要主库接受到一个从库的应答，就会返回事务执行完成。而这时当请求打到未完成同步的从库上时就会发生主从延迟。

所以针对一主多备的情况，我们可以将目光集中在执行查询的从库上，即确保 我们即将查询的备库已经执行了我们预期的事务。 那么我们的问题就变成两部分：1 确认主库事务，2 查询数据条件。

确认主库事务

当我们提交完一个事务后，可以通过执行show master status来得到主库中的数据事务文件（File）和位置记录（Position）。

查询数据条件

当我们要查询从库数据的时候，我们可以通过语句select master_pos_wait(File, Position, 1);来查询当前是否已经执行到了该记录（当返回值>=0的时候说明已经执行过了）。其中最后的数字1表示阻塞时长。

通过先确认主库事务记录，再判确认备库是否已经执行了了主库对应的事务。

但是可以发现，这种方法要求查询的时候知道主库的事务信息，对场景有很大的限制。

主从一致的问题源自主从延迟，所以我们就是从如何消除延迟来解决问题。简单点的方案我们可以不走备库、或者直接等待一段时间来忽略延迟的影响。在一主一备的情况下我们可以粗力度的用seconds_behind_master来判断或者用Relay_Master_Log_File和Exec_Master_Log_Pos来判断。而当一主多从的情况下我们则需要在查询前传入主库执行的事务记录才能保证数据一致性。

可以看出，当数据规模和部署方式变更的时候，好的解决方案将会越来越多。我认为根据实际业务情况选择最合适的方法才是最重要的。

以上就是关于C# 分离数据库全部的内容，包括:C# 分离数据库、sql分离数据库的命令怎么写、sql分离数据库的命令怎么写等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！