标签: backup

我正在使用 Visual Studio 创建一个 VC# 应用程序。启动时，它会打开一个 MDF 文件（SQL Server Express 数据库）。

当我执行

BACKUP DATABASE db.mdf TO DISK=backup.mdf

我创建了 backup.mdf。

然后我执行以下操作：

1. 关闭应用程序
2. 删除 db.mdf
3. 将 backup.mdf 重命名为 db.mdf
4. 运行应用程序

我收到错误“用户‘PC\User’登录失败”

我该如何解决这个问题？

我在 SQL Server 2008 R2 上的完整恢复模型中有一个简单的数据库备份脚本：

backup database livendb to disk = '\\ehsjmaydb01\Data\livendb.bak' with init, format
backup log livendb to disk =  '\\ehsjmaydb01\Data\livendb_log.tran' with init, format  

我们在周末打开了一个新的 ETL 脚本，这绝对让我糟糕的服务器崩溃了。事务日志已满，TempDB 已满。

查看我的备份作业的历史记录，它失败并显示以下消息：

数据库“liveendb”的事务日志已满。
要找出无法重用日志中的空间的原因，请参阅 sys.databases
[SQLSTATE 42000] (Error 9002) BACKUP DATABASE is termination异常中的 log_reuse_wait_desc 列。
[SQLSTATE 42000]（错误 3013）。步骤失败。

当我来到这个早上，我能够备份日志第一，然后运行DB备份，而这工作得很好。

问题：为什么数据库备份过程需要日志文件中的空间？

多年来，我们一直在使用事实上的标准 Ola Hallengrin 维护解决方案，即使在我们迁移到 Azure 并开始使用 blob 作为备份目标之后也是如此。但是，出于性能原因，我一直在研究通过块 blob 而不是页 blob 进行备份，利用具有共享访问签名而不是凭据的存储容器，并一次使用 4-8 个 URL 路径进行备份和恢复。结果非常清晰 - 未压缩备份的恢复性能为 30MB/s，压缩备份的恢复性能为 70MB/s，每个都有 1x URL。使用 4x URL，MAXTRANSFERSIZE = 4194304，& BLOCKSIZE = 65536，.. 131MB/s。使用 8x URL，245MB/s。备份也有类似的故事。

我写信是想看看是否有人知道继续利用 Ola 软件包的方法。似乎包中的 URL 支持结构适用于基于凭据的页面 blob，但没有任何用于 SAS 和条带化 URL 的逻辑。我从没想过这会有什么不同，但这是白天和黑夜。

我从这个文档开始并努力取得成功：https : //blogs.msdn.microsoft.com/sqlcat/2017/03/10/backing-up-a-vldb-to-azure-blob-storage/

下面的测试数据库在磁盘上大约为 85GB，始终压缩到 44GB。

BACKUP DATABASE [yeahokyeahok] TO  
 URL = N'https://az1yeahok01.blob.core.windows.net/adamtest01/yeahokyeahok_backup_2018_03_08_194161.bak'  
,URL = N'https://az1yeahok01.blob.core.windows.net/adamtest01/yeahokyeahok_backup_2018_03_08_194161_2.bak' 
,URL = N'https://az1yeahok01.blob.core.windows.net/adamtest01/yeahokyeahok_backup_2018_03_08_194161_3.bak' 
,URL = N'https://az1yeahok01.blob.core.windows.net/adamtest01/yeahokyeahok_backup_2018_03_08_194161_4.bak' 
--,URL = N'https://az1yeahok01.blob.core.windows.net/adamtest01/yeahokyeahok_backup_2018_03_08_194161_5.bak' 
-- URL = N'https://az1yeahok01.blob.core.windows.net/adamtest01/yeahokyeahok_backup_2018_03_08_194161_6.bak'
WITH NOFORMAT, NOINIT,  NAME = N'yeahokyeahok-Full Database Backup', …

我们在我们的 SQL Server 环境中使用Ola Hallengren的SQL Server 备份解决方案。今天，有 2 个数据库处于SUSPECT模式，无法对它们进行备份。一项作业计划备份这些数据库（其中两个处于可疑模式）和另一个数据库。在线数据库的备份已完成，因为它是按字母顺序排列的第一个，对于其他两个，它失败了。但是，作业并没有失败，并且显示作业成功！如果该作业无法备份任何数据库，则该作业应该失败。

https://i.stack.imgur.com/n8Ww1.png

来自日志的消息：

Date and time: 2018-03-18 03:12:55
Database: [ABC]
Status: SUSPECT
Standby: No
Updateability: READ_WRITE
User access: MULTI_USER
Recovery model: FULL
Differential base LSN: 5334862000009909000054
Last log backup LSN: N/A

Date and time: 2018-03-18 03:12:55
Database: [CDE]
Status: SUSPECT
Standby: No
Updateability: READ_WRITE
User access: MULTI_USER
Recovery model: FULL
Differential base LSN: 4543119000022597000098
Last log backup LSN: N/A

Date and time: 2018-03-18 …

我正在重新编写我们的维护计划，目前重点是备份。在准备此计划时，我想尝试确保程序到位，以确保备份性能最佳。我知道实施以下内容，但是我想了解如何在该范围之外进行改进。

当前考虑：

• 备份压缩
• 大型数据库的多个数据文件 - 可能超过 100GB？
• 将备份写入另一个 I/O 子系统
• 定义参数值，包括 BLOCKSIZE、MAXTRANSFERSIZE 和 BUFFERCOUNT
• 清除旧文件
• 删除备份历史

除了上述之外，还有什么是有利于实施的。另外，在设置 BLOCKSIZE、MAXTRANSFERSIZE 和 BUFFERCOUNT 的值时，我是否应该考虑/如何定义正确的值？我很欣赏测试过程中的一些反复试验，但了解最佳实践会很有用。

为了了解我的日常工作，我将运行每小时事务日志备份、每日差异和每周完整备份。

谢谢

use master
go
ALTER DATABASE Apcore SET SINGLE_USER WITH ROLLBACK IMMEDIATE 

RESTORE DATABASE Apcore
FROM DISK=N'C:\Backups\QG-V-SQL-TS$AIFS_DEVELOPMENT_APCore_FULL_20180909_230034.bak'
WITH  FILE = 1,  
MOVE N'APCoreDataPrimary' TO N'C:\Program Files\Microsoft SQL Server\MSSQL13.DEVELOPMENT\MSSQL\DATA\APCoreDataPrimary.mdf',
MOVE N'APCoreData1' TO N'C:\Program Files\Microsoft SQL Server\MSSQL13.DEVELOPMENT\MSSQL\DATA\APCoreData1.ndf',
MOVE N'APCoreData_nonclusteredIndexes' TO N'C:\Program Files\Microsoft SQL Server\MSSQL13.DEVELOPMENT\MSSQL\DATA\APCoreData_nonclusteredIndexes.ndf',  
MOVE N'APCoreLog_log' TO N'C:\Program Files\Microsoft SQL Server\MSSQL13.DEVELOPMENT\MSSQL\DATA\APCoreLog_log.ldf',  
recovery,  NOUNLOAD,  REPLACE,  STATS = 1

在开发人员的机器上恢复数据库时，出现上述错误。

我这样做的方式是：

• 首先让我说我不担心 - 权限、索引、触发器、同义词等。
• 我将备份文件（小于 1 GB）从 live 复制到她的本地机器
• 做了restore filelestonly这是确定
• 我不得不将数据库设置为 single_user 模式，因为有一些服务每秒钟都在尝试使用它
• 准备好上面的脚本，并在运行它时收到该错误消息。

会是什么呢？

我杀死了一个 80 MB 数据库的备份作业，它已经回滚了好几天......

我试图将数据库带入单用户模式，但那太挂在回滚状态。

我尝试杀死连接到数据库的所有会话，但仍然无法删除它。我用这个脚本来完成杀戮：

DECLARE @kill varchar(8000) = ''; SELECT @kill = @kill + 'kill ' + 
    CONVERT(varchar(5), session_id) + ';' 
FROM sys.dm_exec_sessions 
WHERE database_id = db_id('fpddev92') 
exec(@kill) 

任务的最新等待类型是CMEMTHREAD。我无法使用不同的名称恢复数据库，因为有一个应用程序在使用它，该应用程序在应用程序中具有硬编码的数据库名称。

如果需要，我可以删除和恢复数据库。我该如何解决这个问题？？？它被暂停。没有阻塞。

恐怕如果我重新启动服务，它只会在启动时进行回滚。

任何帮助是极大的赞赏！我一生中从未见过这样的事情......

我对 DBA 和 SQL 没有真正的经验，所以我需要你的一些建议。

我有一个生产数据库备份文件，但是它非常大，所以当我执行恢复时，例如，在测试环境中制作数据副本 - 恢复需要很长时间。

我读到：是否可以从备份中部分恢复数据？

它与我想做的类似，但不完全等效。

为了清楚起见，我需要回答以下问题：是否有可能用比备份文件中更少的记录来恢复数据库？

比如备份文件表有100万条记录，我只想恢复1k条记录。

设想：

• DB被复制到两个可用区（为了高可用）
• 每天在地理位置不同的位置备份数据库（用于灾难恢复）

应用程序级用户事件存储在数据库中（用于应用程序级审计/历史记录）。这意味着时间点恢复可能不会发生在 DB 级别，而是发生在应用级别，除非 rouge 应用程序用户故意弄乱整个 DB，使 DB 级别恢复更实用。

我的问题是，日常数据库备份的合理保留策略是什么？例如，存储 30 天的备份有意义吗？在这个典型场景中，一般的最佳实践是什么？

系统管理员为我提供了一个特定的域帐户来处理备份。我有点困惑，因为我过去从未获得过单独的域帐户来处理备份。我仍然想使用 Agent 来处理这个问题，所以我认为他们正在考虑以下问题：

如果您在代理帐户下运行作业，则代理必须是域帐户。将该帐户添加到 sysadmin 服务器角色并授予它对目录和网络共享的完全控制权。

所以我已经完成了我认为上面描述的事情，我添加了域帐户作为登录名，我创建了一个凭证和代理，并且我将作业步骤创建为 CmdExec 以在代理下运行，但我仍然得到：

操作系统错误 5（访问被拒绝。）。

直到我授予对运行 SQL Server 服务的服务帐户的访问权限后，我才能备份到此网络共享。我还担心恢复，我想利用代理来处理清理任务并将文件随着时间的推移移动到各个目录。

所以我不确定这里发生了什么，但我认为服务帐户至少需要写访问权限？一位系统管理员说他知道有人将备份过程作为“单独的服务”进行，我不太明白，除非它像 ApexSQL 备份之类的东西......