如何将sql2005数据库命令备份和还原

Posted 2023-03-18

首先、点击桌面的“SQL Server Management Studio”打开，sql2005的管理器，点击“连接”登录：

一、新建数据库
1、新建数据库
右键点击“数据库”——“新建数据库”：

MSSQL2005备份还原图文教程
填写数据库名，如mydata，选择数据库保存路径，一般可以保持默认地址，点击“确定”。
2、新建用户
右键点击“安全性”——“登录名”——“新建登录名”：

MSSQL2005备份还原图文教程
填写登录名，如mydata。选择“SQL server身份验证”，输入密码。下方的“强制密码过期”不要选择，默认数据库选择您用户登陆对应的数据库，如mydata。如图：

点击“用户映射”，“映射到此登录名的用户”勾选对应的数据库，如mydata。数据库成员角色勾选“public”和“db_owner”，点“确定”。如图：

至此新建数据库就完成了。
二、还原数据库
首先将数据库备份bak文件上传到服务器，建议放到d:\\mssql 目录 ，如mydata.bak。右键点击要还原的数据库，选择“任务”——“还原”——“数据库”，如图：

注意，如果放在其他目录，务必保证该目录先加上mssqluser的完全控制权限，否则还原或备份会失败。保存备份的目录也必须有这个权限！！
若不是本服务器上早期的备份，请选择“源设备”，点右侧的“…”查找bak文件，完成后下方会显示出备份集，“还原”那勾选：

然后点击“选项”，勾选“覆盖现有数据库”，“将数据库文件还原为：”的文件路径指向现在的数据库文件，点击“确定”就开始还原了，备份太大的话，还原时间要稍微长点：

还原成功后，系统会提示：

还原成功后，请检查下表的架构是否是dbo：

若是数据库名或其他架构，如为mydata架构，需要在“安全性”——“架构”，新建一个所有者为dbo的mydata架构。

新建一个所有者为dbo的mydata架构：

三、附加数据库
首先将您的数据库mdf和ldf文件上传到服务器的某个目录（一般不要放在系统盘，以免系统损坏造成数据丢失），比如d:\\mssql目录，并给该目录mssqluser的完全控制权限。
注意，如果放在其他目录，务必保证该目录先加上mssqluser的完全控制权限，否则还原或备份会失败。保存备份的目录也必须有这个权限！！
其次，右键点击您的数据库，选择附加：

点击添加，添加您的mdf文件：

点击确定就可以附加成功数据库了，在数据库中能看到新附加的数据库：

注意，如果放在其他目录，务必保证该目录先加上mssqluser的完全控制权限，否则还原或备份会失败。保存备份的目录也必须有这个权限！！ 参考技术A SQL Server 2000 数据库备份与还原在查询分析器中,使用 SQL 命令备份系统数据库或用户数据库,然后又使用 SQL 命令 还原数据库. 一,备份数据库
例如: BACKUP DATABASE Northwind TO DISK = 'c:\Northwind.bak'
二,还原数据库
例如: --返回由备份集内包含的数据库和日志文件列表组成的结果集
返回由备份集内包含的数据库和日志文件列表组成的结果集
RESTORE FILELISTONLY FROM DISK = 'c:\Northwind.bak'
--还原由 BACKUP 备份的数据库
还原由 RESTORE DATABASE Northwind FROM DISK = 'c:\Northwind.bak'
--指定还原后的数据库物理文件名称及路径,这里得在 SQL Server 数据库管理系统中,
先 指定还原后的数据库物理文件名称及路径, 数据库管理系统中, 指定还原后的数据库物理文件名称及路径
创建数据库名为 Test 的数据库, 的数据库, 并且指定 mdf 文件和 ldf 文件在 C 盘 test 文件夹下. 文件夹下.否则,
否则, 在还原的时候,找不到指定的路径. 在还原的时候,找不到指定的路径.
RESTORE DATABASE Test FROM DISK = 'c:\Northwind.bak' WITH MOVE 'Northwind' TO 'c:\test\testdb.mdf', MOVE 'Northwind_log' TO 'c:\test\testdb.ldf' MOVE 'logical_file_name' TO 'operating_system_file_name'本回答被提问者采纳

怎么备份和还原mysql数据库

备份数据库

使用mysqldump命令备份数据库

还原数据库

1、使用mysql命令还原数据库

将game_backup.sql 还原至 game 数据库：

2、使用source命令还原数据库

如果数据库过大，建议可以使用source命令

参考技术A MySQL数据库备份与还原
备份和恢复数据
生成SQL脚本
在控制台使用mysqldump命令可以用来生成指定数据库的脚本文本，但要注意，脚本文本中只包含数据库的内容，而不会存在创建数据库的语句！所以在恢复数据时，还需要自已手动创建一个数据库之后再去恢复数据。
mysqldump –u用户名 –p密码 数据库名>生成的脚本文件路径
现在可以在C盘下找到mydb1.sql文件了！
注意，mysqldump命令是在Windows控制台下执行，无需登录mysql！！！
执行SQL脚本
执行SQL脚本需要登录mysql，然后进入指定数据库，才可以执行SQL脚本！！！
执行SQL脚本不只是用来恢复数据库，也可以在平时编写SQL脚本，然后使用执行SQL 脚本来操作数据库！大家都知道，在黑屏下编写SQL语句时，就算发现了错误，可能也不能修改了。所以我建议大家使用脚本文件来编写SQL代码，然后执行之！
SOURCE C:\mydb1.sql
注意，在执行脚本时需要先行核查当前数据库中的表是否与脚本文件中的语句有冲突！例如在脚本文件中存在create table a的语句，而当前数据库中已经存在了a表，那么就会出错！
还可以通过下面的方式来执行脚本文件：
mysql -uroot -p123 mydb1<c:\mydb1.sql
mysql –u用户名 –p密码 数据库<要执行脚本文件路径

这种方式无需登录mysql！ 参考技术B

前言

MySQL 5.6引入了GTID，每个事务都会产生一个GTID，我们可以通过验证主从GTID来验证主从数据的一致性。

为了叙述简便，定义一个量ALL_GTID: 表示某个数据库实例上 所有存在过的 或 将要存在的事务 的GTID（包括已经被purge掉的事务）。

在讨论数据库可用性的场景中, 当发生主备切换时, 需要进行数据补偿。通过比较主备的ALL_GTID，可以确定需要补偿多少数据:

在实例存活的情况，可以在实例状态中查询ALL_GTID。

在实例崩溃的情况，无法在实例状态中查询ALL_GTID。可以通过查询BINLOG中的Previous-GTIDs计算来获得ALL_GTID。

下面列举与ALL_GTID相关的变量。

与ALL_GTID相关的变量

Previous-GTIDs

Previous-GTIDs格式如下（环境为MySQL5.7，日志手动flush binary logs获得）：

查看新轮转出的BINLOG：


下面为mysql-bin.00001中包含的GTID：

请点击输入图片描述


然后再次flush binary logs:

请点击输入图片描述


mysql-bin.00002中是没有任何GTID的。

请点击输入图片描述


综上Previous-GTIDs是本身这个BINLOG文件前面的所有BINLOG的集合。

请点击输入图片描述

全局变量中的GTID相关的变量

请点击输入图片描述

变量解释:


gtid_executed 代表着server上所有事务执行产生的GTID（包含已经被purge的BINLOG中的GTID或者是手动set gtid_purged的GTID）。

gtid_purged 代表着已经被purge到的GTID。gtid_purged是gtid_executed的子集。

gtid_retrieved 是从机上relay_log中的GTID。

ALL_GTID 的计算

了解了GTID相关的变量之后，可以得到获得实例的All_GTID的集合的方法：

对象

方法

存活的Master实例    gtid_executed    

存活的Slave实例    gtid_executed和gtid_retrieved的并集    

非存活Master实例    最后一个BINLOG文件的Previous-GTIDs + 最后一个BINLOG文件中所有的GTID    

非存活Slave实例    最后一个BINLOG文件的Previous-GTIDs + 最后一个BINLOG文件中所有的GTID    

在获得非存活实例中的ALL_GTID时，最后一个BINLOG文件中的GTID可能不连续(比如事务同时来自于本实例客户端和复制回放)，所以需要扫描最后一个BINLOG文件。

生产中我们使用Xtrabackup来产生一个 从实例 的流程如下：

拉取备份，进行还原

change master to

set @@global.gtid_purged='xxx';

set @@global.gtid_purged='xxx'; 的影响:

将 从实例 的ALL_GTID手工置为xxx, 在通过GTID方式建立复制时不会出错.

将更新Binlog中记录的Previous-GTIDs (由于Binlog不可改变, 将产生新的Binlog, 记录新的Previous-GTIDs).

MySQL 5.7中set gtid_purged的行为变更

问题描述

回顾一下备份恢复的流程:

拉取备份，进行还原

change master to

set @@global.gtid_purged='xxx';

现象: 发现有一台MySQL 5.7的Slave服务器恢复后没有产生 正确的Previous-GTIDs。

分析

分析整个过程，解决问题应该分阶段进行手动模拟发现问题。以下为详细步骤：

手工还原备份

环境

BINLOG数量，Previous-GTIDs状态

Xtrabackup 2.4.2 & MySQL 5.6    1，空    

Xtrabackup 2.4.2 & MySQL 5.7    1，空    

Xtrabackup 2.2.9 & MySQL 5.6    1，空    

Xtrabackup 2.2.9 & MySQL 5.7    1，空    

可见: 恢复过程不会轮转BINLOG。

验证change master和set gtid_purged在不同的MySQL版本中执行的差异

环境

BINLOG数量，Previous-GTIDs状态

change master & MySQL 5.6    1，空    

change master & MySQL 5.7    1，空    

set gtid_purged & MySQL 5.6    2，正常    

set gtid_purged & MySQL 5.7    1，空    

可见: 执行set gtid_purged时不同版本的MySQL产生了差异

验证

对不同版本MySQL单独执行set @@global.gtid_purged='';语句。检查结果

环境

进行的操作

BINLOG数量，Previous-GTIDs状态

MySQL 5.7    reset master; set @@global.gtid_purged=”;    1，空    

MySQL 5.6    reset master; set @@global.gtid_purged=”;    2，正常    

结论

参考: http://bugs.mysql.com/bug.php?id=75767

官方解释: 在5.7版本中，执行SET GTID_PURGED语句后binlog_simple_gtid_recovery会给GTID_PURGED计算出一个错误的值。

由于5.7中新增了存储GTID的表。所以5.7版本中set @@global.gtid_purged='';语句被改成只修改存放GTID的表。

而5.6版本中会进行BINLOG轮转和向Previous_gtids_log_event中添加GTID。如果5.7需要产生和5.6相同结果的话，可以在SET GTID_PURGED语句后手动执行flush binary logs语句。