怎样用SQL语句完整复制数据库

SQL六种数据移动方法

1. 通过工具DTS的设计器进行导入或导出

DTS的设计器功能强大，支持多任务，也是可视化界面，容易 *** 作，但知道的人一般不多，如果只是进行SQL Server数据库中部分表的移动，用这种方法最好，当然，也可以进行全部表的移动。在SQL Server Enterprise Manager中，展开服务器左边的+，选择数据库，右击，选择All tasks/Import Data...(或All tasks/Export Data...)，进入向导模式，按提示一步一步走就行了，里面分得很细，可以灵活的在不同数据源之间复制数据，很方便的。而且可以另存成DTS包，如果以后还有相同的复制任务，直接运行DTS包就行，省时省力。也可以直接打开DTS设计器，方法是展开服务器名称下面的Data Transformation Services，选Local Packages，在右边的窗口中右击，选New Package，就打开了DTS设计器。值得注意的是：如果源数据库要拷贝的表有外键，注意移动的顺序，有时要分批移动，否则外键主键，索引可能丢失，移动的时候选项旁边的提示说的很明白，或者一次性的复制到目标数据库中，再重新建立外键，主键，索引。

其实建立数据库时，建立外键，主键，索引的文件应该和建表文件分开，而且用的数据文件也分开，并分别放在不同的驱动器上，有利于数据库的优化。

2. 利用Bcp工具

这种工具虽然在SQL Server7的版本中不推荐使用，但许多数据库管理员仍很喜欢用它，尤其是用过SQL Server早期版本的人。Bcp有局限性，首先它的界面不是图形化的，其次它只是在SQL Server的表（视图）与文本文件之间进行复制，但它的优点是性能好，开销小，占用内存少，速度快。有兴趣的朋友可以查参考手册。

3. 利用备份和恢复

先对源数据库进行完全备份，备份到一个设备（device）上，然后把备份文件复制到目的服务器上（恢复的速度快），进行数据库的恢复 *** 作，在恢复的数据库名中填上源数据库的名字（名字必须相同），选择强制型恢复（可以覆盖以前数据库的选项），在选择从设备中进行恢复，浏览时选中备份的文件就行了。这种方法可以完全恢复数据库，包括外键，主键，索引。

4. 直接拷贝数据文件

把数据库的数据文件（*.mdf）和日志文件（*.ldf）都拷贝到目的服务器，在SQL Server Query Analyzer中用语句进行恢复:

EXEC sp_attach_db @dbname = 'test ',

@filename1 = 'd:\mssql7\data\test_data.mdf ',

@filename2 = 'd:\mssql7\data\test_log.ldf '

这样就把test数据库附加到SQL Server中，可以照常使用。如果不想用原来的日志文件，可以用如下的命令：

EXEC sp_detach_db @dbname = 'test '

EXEC sp_attach_single_file_db @dbname = 'test ',

@physname = 'd:\mssql7\data\test_data.mdf '

这个语句的作用是仅仅加载数据文件，日志文件可以由SQL Server数据库自动添加，但是原来的日志文件中记录的数据就丢失了。

5. 在应用程序中定制

可以在应用程序（PB、VB）中执行自己编写的程序，也可以在Query Analyzer中执行，这种方法比较灵活，其实是利用一个平台连接到数据库，在平台中用的主要时SQL语句，这种方法对数据库的影响小，但是如果用到远程链接服务器，要求网络之间的传输性能好，一般有两种语句：

1> select ... into new_tablename where ...

2> insert (into) old_tablename select ... from ... where ...

区别是前者把数据插入一个新表（先建立表，再插入数据），后者是把数据插入已经存在的一个表中，我个人喜欢后者，因为在编程的结构上，应用的范围上，第二条语句强于前者。

6. SQL Server的复制功能

SQL Server提供了强大的数据复制功能，也是最不易掌握的，具体应用请参考相关资料，值得注意的是要想成功进行数据的复制工作，有些条件是必不可少的：

1>SQL Server Agent必须启动，MSDTC必须启动。

2>所有要复制的表必须有主键。

3>如果表中有text或image数据类型，必须使用with log选项，不能使用with no_log选项。

另外max text repl size选项控制可以复制的文本和图像数据的最大规模，超过这个限制的 *** 作将失败。

4>在要进行复制的计算机上，应该至少是隐含共享，即共享名是C$或D$…。

5>为SQL Server代理使用的Windows NT帐号不能是一个本地的系统帐号，因为本地的系统帐号不允许网络存取。

6>如果参与复制的服务器在另外的计算机域中，必须在这些域之间建立信任关系。

如果从库上表 t 数据与主库不一致，导致复制错误，整个库的数据量很大，重做从库很慢，如何单独恢复这张表的数据？通常认为是不能修复单表数据的，因为涉及到各表状态不一致的问题。下面就列举备份单表恢复到从库会面临的问题以及解决办法：

场景 1

如果复制报错后，没有使用跳过错误、复制过滤等方法修复主从复制。主库数据一直在更新，从库数据停滞在报错状态（假设 GTID 为 aaaa:1-100）。

修复步骤：

在主库上备份表 t （假设备份快照 GTID 为 aaaa:1-10000）；

恢复到从库；

启动复制。

这里的问题是复制起始位点是 aaaa:101，从库上表 t 的数据状态是领先其他表的。aaaa:101-10000 这些事务中只要有修改表 t 数据的事务，就会导致复制报错 ，比如主键冲突、记录不存在（而 aaaa:101 这个之前复制报错的事务必定是修改表 t 的事务）

解决办法：启动复制时跳过 aaaa:101-10000 这些事务中修改表 t 的事务。

正确的修复步骤：

1. 在主库上备份表 t （假设备份快照 GTID 为 aaaa:1-10000），恢复到从库；

2. 设置复制过滤，过滤表 t：

CHANGE REPLICATION FILTER REPLICATE_WILD_IGNORE_TABLE = ('db_name.t')

3. 启动复制，回放到 aaaa:10000 时停止复制（此时从库上所有表的数据都在同一状态，是一致的）

START SLAVE UNTIL SQL_AFTER_GTIDS = 'aaaa:10000'

4. 删除复制过滤，正常启动复制。

注意事项：这里要用 mysqldump --single-transaction --master-data=2，记录备份快照对应的 GTID

场景 2

如果复制报错后，使用跳过错误、复制过滤等办法修复了主从复制。主、从库数据一直在更新。

修复步骤：

在主库上备份表 t （假设备份快照 GTID为 aaaa:1-10000）；

停止从库复制，GTID为 aaaa:1-20000；

恢复表 t 到从库；

启动复制。

这里的问题是复制起始位点是 aaaa:20001，aaaa:10000-20000 这些事务将不会在从库上回放，如果这里面有修改表 t 数据的事务，从库上将丢失这部分数据。

解决办法：从备份开始到启动复制，锁定表 t，保证 aaaa:10000-20000 中没有修改表 t 的事务。

正确修复步骤：

对表 t 加读锁；

在主库上备份表 t；

停止从库复制，恢复表 t；

启动复制；

解锁表 t。

如果是大表，这里可以用可传输表空间方式备份、恢复表，减少锁表时间。

---