标签: backup

我有一个运行 MySQL 5.5 的 Enterprise Linux 6 系统。我正在尝试使用LVM 捕获每周文件系统快照。

然而，正如我们许多人所经历的那样，“用读锁刷新表；” 可能会导致死锁情况、造成查询积压、填满连接池并导致系统脱机。事实上，昨晚我的“用读锁刷新表；” 由于长时间运行的查询，直到执行后 8 小时才完成。

如果我使用这样的脚本执行 MySQL 快照，我可以以某种方式使“FLUSH TABLES WITH READ LOCK;”超时吗？如果它在一段时间后没有执行，我想杀死它并避免不可避免的死锁。

mysql -u root <<-MYSQL_INPUT
FLUSH TABLES WITH READ LOCK;
SYSTEM /usr/local/bin/mysql-create-lvm-snapshot;
UNLOCK TABLES;
\q
MYSQL_INPUT

最近，我的 ~40Gb 数据库中经常出现许多一致性错误。当然，我使用DBCC CHECKDB, 即使REPAIR_ALLOW_DATA_LOSS（当它询问时），但是我再次遇到错误，即使在只读操作之后也是如此。

数据库本身存储在 SSD 驱动器上，这没问题，所以我怀疑数据库文件中存在一些隐藏的错误。

所以，完整的周期：我在本地 PC 上安装了 MSSQL 2016，只连接了 1 个用户。每天我都以自定义格式获取数据（~1.5M 记录），备份基础并将数据插入基础（非批量插入，索引）。在那次行动中，没有人接触基地。后来我不时进行高负载查询（不同的统计数据）。我经常遇到一致性错误、校验和错误、索引错误（目前没有存储确切的输出）。可以通过重建索引来纠正索引错误；其他人只能通过DBCC CHECKDB使用该REPAIR_ALLOW_DATA_LOSS选项来修复。之后，它再次工作 - 一段时间。

我不相信问题出在我的 SSD 驱动器上。在过去的几年里，我在这台 PC 上尝试了不同的驱动器，行为没有改变。

我怀疑，即使在DBCC CHECKDB成功运行后，文件结构中也存在一些隐藏的错误，这些错误会导致以后出现新的错误。所以我只想将数据提取到线性文件然后导入。标准导出向导导出数百行，然后停止没有错误。

是否有一种正确且可靠的方法可以将整个数据库导出到文本/二进制文件（但不是 mssql），然后重新创建数据库而不会丢失这些文件中的数据？我尝试了备份还原，但看起来数据库一致性问题在还原过程中仍然存在。

晚上 10 点，我安排了一个 SQL 代理作业，按照时间表进行每日备份：

• 每日全场：22:00
• 差价：每4小时
• 日志：每 30 分钟

现在，当我检查我的备份集时（假设在 22:30），我看到差异备份已经发生，而没有任何完整备份！！。

我没想到会在明天 16:00 之前第一次完全备份发生时看到备份作业启动并运行，但是，我有一个没有完整备份的差异备份？这怎么可能？

我是 DBA 新手，在学习不同类型的备份时，我想到了一个问题。所以问题是，上次差异备份中会有什么，只是之前差异备份的总和或之前备份加上 t-log 备份的总和？假设我有以下备份：

full_backup_2018_05_09_000000.bak
tran_backup_2018_05_09_003500.trn
tran_backup_2018_05_09_004000.trn
diff_backup_2018_05_09_004500.bak
tran_backup_2018_05_09_005000.trn
tran_backup_2018_05_09_005500.trn
diff_backup_2018_05_09_006000.bak
tran_backup_2018_05_09_006500.trn
tran_backup_2018_05_09_007000.trn
tran_backup_2018_05_09_007500.trn
diff_backup_2018_05_09_008000.bak

我有一个来自 SQL 2016 服务器的备份文件，我需要确定该文件是在哪个 SQL 服务器上创建的。有没有办法识别文件起源的原始 SQL 服务器？谢谢你。

我正在考虑在 VPS 上安装 SQL Server Express Edition。

我的理解是，在 Express Edition 的限制中，其中一些涉及便于备份的功能。

有人可以解释一些为此配置执行每日备份的选项吗？有没有直接的方法，还是我需要购买额外的软件？

（对不起，如果这个问题看起来很愚蠢。我是一名软件开发人员，根本不是数据库或管理员。）

我们的备份驱动器充满了 TRN 和 BAK 文件。我在服务器上有管理权限，但我没有登录数据库。

我可以将最旧的文件移到其他地方而不导致服务中断吗？哪个？

我是从 Oracle DBA 背景开始学习 SQL Server 数据库管理的。所以也许很自然，我总是试图了解两个 DBMS 之间的差异以及相似之处。最近让我印象深刻的一个问题是，日志记录是否应该多次备份，如何备份？在 Oracle 数据库中，假设数据库处于“Archive-Log”数据库模式，“redo”日志文件被归档为单独的“archived redo log”文件，其作用在时间点恢复的情况下至关重要方案，因此，定期备份这些文件非常重要。很多时候，DBA 对每个“归档重做日志”文件进行多次备份，例如，如果某个特定磁带丢失或损坏，在其他备份设备上的其他地方仍然可以使用相同备份的另一个副本。这显然将提供高级别的数据丢失保护。

众所周知，在SQL Server中，有包含日志记录的事务日志，它对执行数据库恢复起着至关重要的作用。现在我的问题是：对于处于“完整”恢复模式的数据库，是否可以多次备份日志记录？如果可能的话，这是个好主意吗？如何做到这一点？

如果我有这个备份策略（每周完整备份和1小时日志备份），我可以将数据库恢复到绿色突出显示的时间段吗？顺便说一句，日志备份 2 是否包括其 lsn 大于日志备份 1 的 last_lsn 的所有日志记录？

我做了更多的测试，我想我找到了答案。根据备份计划中的映像，我做了一个初始完整备份，一些日志备份，然后日志备份 1，完整备份，日志备份 2。我在两者之间进行了修改。使用RESTORE HEADERONLY检查日志备份1，完全备份和日志备份2，下面是我得到了什么。如您所见，日志备份 2 捕获了日志备份 1 中最后一条的所有日志记录。如果我想恢复到绿色突出显示期间的某个点，我需要使用日志备份 2，而不是完整备份。

在对我公司的问题进行故障排除时，我更新了表中的所有文件，而不是需要使用测试的特定文件。

create table _file_*date*_BAK as select * from _file;
update _file set category = 'null'; 
commit;

尝试修复它时，我尝试从备份文件中提取，但出现错误

update (select a.category as OLD, b.category as NEW

 from _file a inner join _file_*date*_BAK b on a.filecod = b.filecod) t

 set t.old = t.new;

错误报告 -

SQL Error: ORA-01779: cannot modify a column which maps to a non key-preserved table
01779. 00000 -  "cannot modify a column which maps to a non key-preserved table"
*Cause:    An attempt was made to insert or update …