1

我刚刚在一夜之间完成了 DR 测试，以便在 Azure SQL 托管实例上运行 PITR。这是一个相当大的数据库（4TB）。我通过使用 Azure CLI 做到了这一点。一旦我执行了命令（见下文）并确保没有错误，我就退出了 CLI。

今天早上恢复工作成功，但我很难找到恢复时间的指标。有谁知道我在哪里可以找到这些指标？

我检查了审计日志，但没有运气，查看了 SQL 中的数据库创建日期，所以我有一个粗略的指示，但我想要可以在这个 DR 报告中引用的可靠数字。

# Restore script I ran
az sql midb restore -g sourceRG --managed-instance sourceMi --name sourceMiDb --dest-resource-group destinationRG --dest-mi destinationMi --dest-name destinationMiDb --time "2019-07-21T10:00:00" --verbose --debug
4

1 回答 1

1

Managed Instance is a bit tricky, since everything is so obfuscated. For a database to become available on a MI, it needs to be both recovered & also replicated to the secondary nodes.

To find out when the database recovered, check out Thomas LaRock's script here: https://www.mssqltips.com/sqlservertip/1724/when-was-the-last-time-your-sql-server-database-was-restored/ 

DECLARE @dbname sysname, @days int
SET @dbname = NULL --substitute for whatever database name you want
SET @days = -30 --previous number of days, script will default to 30
SELECT
 rsh.destination_database_name AS [Database],
 rsh.user_name AS [Restored By],
 CASE WHEN rsh.restore_type = 'D' THEN 'Database'
  WHEN rsh.restore_type = 'F' THEN 'File'
  WHEN rsh.restore_type = 'G' THEN 'Filegroup'
  WHEN rsh.restore_type = 'I' THEN 'Differential'
  WHEN rsh.restore_type = 'L' THEN 'Log'
  WHEN rsh.restore_type = 'V' THEN 'Verifyonly'
  WHEN rsh.restore_type = 'R' THEN 'Revert'
  ELSE rsh.restore_type 
 END AS [Restore Type],
 rsh.restore_date AS [Restore Started],
 bmf.physical_device_name AS [Restored From], 
 rf.destination_phys_name AS [Restored To]
FROM msdb.dbo.restorehistory rsh
 INNER JOIN msdb.dbo.backupset bs ON rsh.backup_set_id = bs.backup_set_id
 INNER JOIN msdb.dbo.restorefile rf ON rsh.restore_history_id = rf.restore_history_id
 INNER JOIN msdb.dbo.backupmediafamily bmf ON bmf.media_set_id = bs.media_set_id
WHERE rsh.restore_date >= DATEADD(dd, ISNULL(@days, -30), GETDATE()) --want to search for previous days
AND destination_database_name = ISNULL(@dbname, destination_database_name) --if no dbname, then return all
ORDER BY rsh.restore_history_id DESC
GO

As for determining when the database is replicated to the secondary nodes...that's tougher to tell. For a DB restore from BLOB storage, it seems the db will first restore, then replicate to the other AG nodes. However, when using Azure CLI like your example... I'm not so sure. My guess is they restore in parallel on each AG node, so it's available the moment the last log file is applied.

enter image description here

Everything you see in the logs will refer to a guid, so to figure out your DB guid you'll need to query sys.databases

SELECT physical_database_name, name FROM sys.databases
于 2019-08-09T16:16:05.563 回答