sqlserver读写分离
A. 分离数据库是什么意思
问题一：数据库分离，什么意思啊？ 一般默认情况下数据库在联机状态下我们不能对数据库文件进行任何复制删除等操作，如果将数据库分离的话就可以对数据文件进行复制、剪切、删除等操作了。一般想直接备份数据文件，就先分离数据库，之后把数据文件复制到别的地方，再把数据文件附加回去就可以了。
备份数据库是将数据库中全部对象以特定格式导成为备份文件，至于格式全部是数据库引擎来使用，用户无需关心。导出数据库是将数据库中某些对象导出为其他格式的文件，一般都是行集的形式。
问题二：什么情况下需要分离数据库？ 比如你想把数据库转移到别的地方，而你又不愿意备份的时候，可以分离然后拷贝文件过去，然后附加上
问题三：sqlserver分离的数据库在哪 默认的路径在：D:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data或者
C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data；不过不行就用搜索功能；其实你分离之前可以先检查其路径：右键--数据库--属性--文件，在此面板上可看到路径
问题四：什么是数据库的读写分离 数据库复制被用来把事务性查询导致的变更同步到集群中的从数据库。对于大访问量的网站，一般会采用读写分离，比如ebay的读写比率是260：1，也就是大型的电子商务网站的。网上看到说采用读写分离有如下工具：1，oracle的logical standby2, Quest公司的SharePlex3, DSG公司的RealSyncMySQLReplication可以将master的数据复制分布到多个slave上，然后可以利用slave来分担master的读压力。那么对于前台应用来说，就要考虑如何将读的压力分布到多个slave上。如果每芦陪个应用都需要来实现读写分离的算法，一则成本太高，二来如果slave增加更多的机器，应用就要随之修改。明显的，如果在应用和数据库间加一个专门用于实现读写分离的中间层，则整个系统的架构拥有更好的扩展性。MySQLProxy就是这么一个中间层代理，简单的说，MySQLProxy就是一个连接池，负责将前台应用的连接请求转发给后台的数据库，并且通过使用lua脚本，可以实现复杂的连接控制和过滤，从而实现读写分离和负载平衡。对于应用来说，MySQLProxy是完全透明的，应用则只需要连接到MySQLProxy的监听端口即可。
问题五：sql server 中数据库分离和删除数据库的区别 分离数据库就相当于是暂停使用，就像把一个火车厢从列车上暂时分离出来放在仓库一样；
删除就和平时陪模蠢的删除没什么两样了，直接干掉它。
问题六：sql server 2008数据库的分离是什么意思 相当于将轮胎（一个Database）从汽车（DBMS）上卸下来。
此时，这个轮胎还是在的（对应到文件），但不能转（即无法访问这个Database）。
问题七：数据库的分离附加与备份还原的区别 分离说的是断开这个数据库的连接（但可不是删除哦，仍然存在于硬盘上，这样就可以随意的挪动数据库了） 。
附加数据库是附加已分离的数据库文件。
备份是对本机服务器里面的数据进行备份。
还原数据库是还原已备份的数据库文件。
问题八：数据库的分离和附加有什么作用？可以说详细点吗？ 一、可以切断数据库的使用 (比如当数据库日志很大占用了空间时，可以用分离数据库的方法来切断数据库，从而删除以前的数据库日志，来节省空间）
实践中碰到 数据库日志 很大（10G）占用了硬盘空间的情况处理：
方法:
1、停掉iis，然后分离数据库
2、修改数据库日志的名字
3、附加数据库，成功后可以删除数据库日志
二、可以在需要更换数据库物理存放地址时使用如果您数据库系统安装在系统盘（比如 C 盘），由于 C 盘容易受病毒侵害，您也许希望您的数据存码悔放在非系统盘（比如 D 盘），要做的这点很简单，您并不需要重装数据库，只要把数据“分离”，然后将相关文件移动到 D 盘的某个目录，接着“附加”数据库即可。
SQL Server 2000允许分离数据库的数据和事务日志文件，然后将其重新附加到同一台或另一台服务器上。分离数据库将从 SQL Server 删除数据库，但是保证在组成该数据库的数据和事务日志文件中的数据库完好无损。然后这些数据和事务日志文件可以用来将数据库附加到任何 SQL Server 实例上，这使数据库的使用状态与它分离时的状态完全相同。
应注意，只有“使用本数据库的连接”数为0时，该数据库才能分离。所以分离数据库时尽量断开所有对要分离数据库操作的连接，如果还有连接数据库的程序，会出现数据库的连接状态窗口，显示正在连接此数据库的机器以及名称，点击清除按钮将从服务器强制断开现有的连接。
问题九：sql分离数据库的命令怎么写 --首先需要使用master数据库进行操作
use master
go
--分离数据库
exec sp_detach_db mydb
go
--附加数据库
exec sp_attach_db mydb,'D:\mydb_data.mdf' --后面是路径
go
B. 电子商务网站数据库备份的方法有哪几种
数据库备份一般有以下几种方案：
直接的电商网站后台，一般都提供数据整理功能，直接导出即可。
数据库第三方管理工具比如mysql的phpmyadmin可以直接连接数据库导出相关数据备份。
服务器直接操作备份，比如mysql的源文件复制备份等等
C. 数据建模的如何进行
概念建模
数据建模大致分为三个阶段，概念建模阶段，逻辑建模阶段和物理建模阶段。其中概念建模和逻辑建模阶段与数据库厂商毫无关系，换言之，与MySQL，SQL Server，Oracle没有关系。物理建模阶段和数据库厂商存在很大的联系，因为不同厂商对同一功能的支持方式不同，如高可用性，读写分离，甚至是索引，分区等。
概念建模阶段
实际工作中，在概念建模阶段，主要做三件事：
1. 客户交流
2. 理解需求
3. 形成实体
这也是一个迭代，如果先有需求，尽量去理解需求，明白当前项目或者软件需要完成什么，不明白或者不确定的地方和客户及时交流，和客户double confirm过的需求，落实到实体（Package）；但是好多时候我们需要通过先和客户交流，进而将交流结果落实到需求，之后进一步具体到实体；本文可能会涉及到一些来自于EA（Enterprise Architect 7.1）建模术语，（EA中将每个实体视为一个Package）。这里并不对各种建模工具进行比较，如Visio，EA，PowerDesigner， ERWin等；其实作为员工的我们选择性很少，公司有哪个产品的Licence，我们就用哪个吧。
举例说明：在一个B2C电子商务网站中，这样的需求再普通不过了：客户可以在该网站上自由进行购物！我们就以这个简单例子，对其进行细分，来讲解整个数据建模的过程，通过上面这句话，我们可以得出三个实体：客户，网站，商品；就像Scrum（敏捷开发框架的一种）中倡导的一样每个Sprint，都要产出确确实实的东西，OK，概念建模阶段，我们就要产出实体。客户和商品（我们将网站这个实体扔掉，不需要它。）
在创建这两个实体（Package）的时候，我们记得要讲对需求的理解，以及业务规则，作为Notes添加到Package中，这些信息将来会成为数据字典中非常重要的一部分，也就是所谓的元数据。BTW，EA或者其他建模工具应该都可以自动生成数据字典，只不过最终生成的格式可能不太一样。如在Customer这个Package的Notes上，我们可以这样写，用户都要通过填写个人基本信息以及一个邮箱来注册账户，之后使用这个邮箱作为登录帐号登录系统进行交易。
在概念建模阶段，我们只需要关注实体即可，不用关注任何实现细节。很多人都希望在这个阶段把具体表结构，索引，约束，甚至是存储过程都想好，没必要！！因为这些东西使我们在物理建模阶段需要考虑的东西，这个时候考虑还为时尚早。可能有的人在这个阶段担心会不会丢掉或者漏掉一些实体?也不用担心，2013年好多公司都在采用Scrum的开发模式，只要你当前抽象出来的实体满足当前的User Story，或者当前的User Story里面的实体，你都抽象出来了，就可以了！如果你再说，我们User Story太大，实体太多，不容易抽象，那就真没办法了，建议你们的团队重新开Sprint 计划会议。
逻辑建模
逻辑建模阶段
对实体进行细化，细化成具体的表，同时丰富表结构。这个阶段的产物是，可以在数据库中生成的具体表及其他数据库对象（包括，主键，外键，属性列，索引，约束甚至是视图以及存储过程）。我在实际项目中，除了主外键之外，其他的数据库对象我都实在物理建模阶段建立，因为其他数据库对象更贴近于开发，需要结合开发一起进行。如约束，我们可以在web page上做JavaScript约束，也可以在业务逻辑层做，也可以在数据库中做，在哪里做，要结合实际需求，性能以及安全性而定。
针对Customer这个实体以及我们对需求的理解，我们可以得出以下几个表的结构，用户基本信息表（User），登录账户表（Account），评论表（Commnets,用户可能会对产品进行评价），当然这个案例中我们还会有更多的表，如用户需要自己上传头像（图片），我们要有Picture表。
针对产品实体，我们需要构建产品基本信息表（Proct），通常情况下，我们产品会有自己的产品大类（ProctCategory）甚至产品小类（ProctSubCategory），某些产品会因为节假日等原因进行打折，因为为了得到更好的Performance我们会创建相应ProctDiscount表，一个产品会有多张图片，因此产品图片表（ProctPicture）以及产品图片关系表（ProctPictureRelationship），（当然我们也可以只设计一张Picture表，用来存放所有图片，用户，产品以及其他）有人说产品和图片是一对多的关系，不需要创建一个关系表啊?是的，我认为只要不是一对一的关系，我都希望创建一个关系表来关联两个实体。这样带来的好处，一是可读性更好，实现了实体和表一一对应的关系，二是易于维护，我们只需要维护一个关系表即可，只有两列（ProctID和PictureID），而不是去维护一个Picture表。
客户进行交易，即要和商品发生关系，我们需要Transaction表，一个客户会买一个或者多个商品，因为一笔Transaction会涉及一个或多个Procts，因此一个Transaction和ProctDiscount之间的关系（ProctDiscount和Proct是一一对应的关系）需要创建，我们称其为Item表，里面保存TransactionID以及这笔涉及到的ProctDiscountID（s），这里插一句，好多系统都需要有审计功能，如某个产品历年来的打折情况以及与之对应的销售情况，我们这里暂不考虑审计方面的东西。
就这样，我们根据需求我们确定下来具体需要哪些表，进一步丰富每一个表属性（Column），当然这里面会涉及主键的选取，或者是使用代理键（Surrogate Key），外键的关联，约束的设置等细节，这里笔者认为只要能把每个实体属性（Column）落实下来就是很不错了，因为随着项目的开展，很多表的Column都会有相应的改动。至于其他细节，不同数据库厂商，具体实现细节不尽相同。关于主键的选取多说一句，有的人喜欢所有的表都用自增长ID作为主键，而有的人希望找到唯一能标识当前记录的一个属性或者多个属性作为主键；自增长ID作为代理主键，对于将来以多个类似当前Transaction System作为数据源，构建数据仓库的时候，这些自增长ID主键会是一个麻烦（多个系统中，相同表存在大量主键重复）；使用一个属性或多个属性作为作为主键，不管主键是可编辑的，读写效率是我们必须考虑得。所以并没有一个放之四海而皆准的原则，笔者只是给大家推荐一些考虑的因素。
物理建模
物理建模阶段
EA可以将在逻辑建模阶段创建的各种数据库对象生成为相应的SQL代码，运行来创建相应具体数据库对象（大多数建模工具都可以自动生成DDL SQL代码）。但是这个阶段我们不仅仅创建数据库对象，针对业务需求，我们也可能做如数据拆分（水平或垂直拆分），如B2B网站，我们可以将商家和一般用户放在同一张表中，但是针对PERFORMANCE考虑，我们可以将其分为两张表；随业务量的上升，Transaction表越来越大，整个系统越来越慢，这个时候我们可以考虑数据拆分，甚至是读写分离（即实现MASTER-SLAVE模式，MYSQL/SQLSERVER可以使用Replication，当然不同存储引擎采用不同的方案），这个阶段也会涉及到集群的事情，如果你是架构师或者数据建模师，这个时候你可以跟DBA说，Alright,I am done with it,now is your show time.
相信大家都知道范式，更有好多人把3NF奉为经典，3NF确实很好，但是3NF是几十年前提出来的，那个时候的数据量以及访问频率和2012年完全不是一个数量级的；因此我们绝对不能一味地遵守3NF；在整个数据建模过程中，在保证数据结构清晰的前提下，尽量提高性能才是我们关注的要点，因此笔者大力倡导数据适当冗余!
上面笔者是结合一些实际例子表达自己对数据建模的观点，希望对读着有用。在数据建模过程中，不要希望一步到位将数据库设计完整，笔者不管是针对data warehouse还是Transactional Database设计，从来没有过一次成功的经历。随着项目的进行，客户和开发团队对业务知识与日增长，因此原来的设计也在不断完善中。毕竟，数据建模或者设计数据库不是我们的最终目的，我们需要的是一个健壮，性能优越，易扩展，易使用的软件!
D. sql2008主从同步 是什么意思
sql server 主从同步是指数据库的主库数据同步到从库中，数据写入到主库，通过sqlserver的复制分发将主库的数据复制到从库中，已达数据库之间数据的一致性；一般在主数据库压力比较大，通过读写分离来给主数据库降压的时候需要用到；写的时候操作主库，读取数据的时候操作从库；从库可以有一个或多个；