主頁 > 資料庫 > SQL Server資料庫判斷最近一次的備份執行結果

SQL Server資料庫判斷最近一次的備份執行結果

2023-05-11 08:36:30 資料庫

1 麻煩的地方

在SQL Server的官方檔案里面可以看到備份和還原的表，但是這些表里面只能找到備份成功的相關資訊，無法找到備份失敗的記錄，比如msdb.dbo.backupset，對于一些監控系統未監控作業的情況下，想要監控資料庫備份任務執行失敗而觸發告警規則，有些麻煩，
但是SQL server內部是可以通過查詢errorlog來判斷資料庫備份作業是否成功：

2 獲取errorlog的trace表

我們可以借助sys.traces定位到errorlog的trace檔案路徑，然后通過再通過fn_trace_gettable將errlog的trace檔案轉換為普通的表來查詢即可，

  1. 定位errorlog的trace檔案物理路徑
SELECT
          REVERSE(
            SUBSTRING(
              REVERSE([path]),
              CHARINDEX(CHAR(92), REVERSE([path])),
              260
            )
          ) + N'log.trc'
        FROM
          sys.traces
        WHERE
          is_default = 1

輸出結果：
image
2. 得到路徑后，使用fn_trace_gettable將errolog的trace檔案轉換為普通的資料表

SELECT
  *
FROM
  sys.fn_trace_gettable(
    'S:\MSSQL13.MSSQLSERVER\MSSQL\Log\log.trc',
    default
  )

image
3. 查找與備份相關的事件記錄，在trace檔案中對應的EventClass為115，并將所有備份開頭的陳述句篩選出來

SELECT
  TextData,Databasename,StartTime
FROM
  sys.fn_trace_gettable(
    'S:\MSSQL13.MSSQLSERVER\MSSQL\Log\log.trc',
    default
  )
WHERE
  EventClass = 115
  AND UPPER(CONVERT(nvarchar(max), TextData)) LIKE 'BACKUP%'

image

從回傳的TextData中沒有找到是否關于備份成功或者失敗的說明，也沒有在其它列中找到相關描述，需要結合msdb.dbo.backupset來判斷，

3 結合備份表backupset，判斷備份狀態

  1. 篩選出所有資料庫的備份任務執行情況

    從查詢的結果可知，每個成功的備份都有1個開始時間和結束時間，考慮將開始時間與trace檔案轉換的表進行對比：
flowchart LR A[trace表的獲取備份記錄和時間]--> B[取得StartTime列] B[與backupset表對比判斷]--> C{是否存在與StartTime列對應的值} C--存在-->D[備份成功] C--不存在-->E[備份失敗]

形成了具體的思路后，下面將trace轉換的表的StartTime列與backupset表的backup_start_date列進行對比判斷
2. 判斷存在對應的值則說明備份成功，不存在則備份失敗

SELECT
  dt.DatabaseName,
  dt.StartTime,
  bs.backup_start_date,
  bs.backup_finish_date,
  [Status] = CASE
    WHEN bs.backup_start_date IS NULL THEN (dt.DatabaseName) + '資料庫備份失敗'
    ELSE (dt.DatabaseName) + '資料庫備份成功'
  END
FROM
  sys.fn_trace_gettable(
    'S:\MSSQL13.MSSQLSERVER\MSSQL\Log\log.trc',
    default
  ) AS dt
  LEFT OUTER JOIN msdb.dbo.backupset AS bs ON dt.DatabaseName = bs.database_name
  AND ABS(
    DATEDIFF(SECOND, dt.StartTime, bs.backup_start_date)
  ) < 5
WHERE
  dt.EventClass = 115
  AND UPPER(CONVERT(nvarchar(max), dt.TextData)) LIKE N'BACKUP%'
ORDER BY
  dt.StartTime DESC;

image

4 形成用于告警的SQL陳述句

完成上面的操作之后，我們已經能夠看到所有資料庫的備份是成功還是失敗的狀態，現在還需要將SQL再度細化，輸出所有資料庫最近一次備份執行成功或者失敗的資訊：即每個資料庫只有一行記錄用于說明最近一次的備份狀態，
下面有兩種寫法可以實作，第1種是游標的寫法，性能極差，后來找chatgpt一起討論之后，采用了group by優化，形成第2種寫法，

  1. 第1種，游標查看每個資料庫最近一次備份狀態
點擊查看代碼 
DBCC FREE
DECLARE @databaseName1 nvarchar(100)
DECLARE @sql nvarchar(4000)

DECLARE db_cursor CURSOR FOR
    SELECT name
    FROM sys.databases
OPEN db_cursor
FETCH NEXT FROM db_cursor INTO @databaseName1

WHILE @@FETCH_STATUS = 0  
BEGIN  
    SET @sql = '
	SELECT
  TOP 1 dt.DatabaseName,
  dt.StartTime,
  bs.backup_start_date,
  bs.backup_finish_date,
  [Status] = CASE
    WHEN bs.backup_start_date IS NULL THEN (dt.DatabaseName) + ''資料庫備份失敗''
    ELSE (dt.DatabaseName) + ''資料庫備份成功''
  END
FROM
  sys.fn_trace_gettable(
    (
      SELECT
        REVERSE(
          SUBSTRING(
            REVERSE([path]),
            CHARINDEX(CHAR(92), REVERSE([path])),
            260
          )
        ) + N''log.trc''
      FROM
        sys.traces
      WHERE
        is_default = 1
    ),
    default
  ) AS dt
  LEFT OUTER JOIN msdb.dbo.backupset AS bs ON dt.DatabaseName = bs.database_name
  AND ABS(
    DATEDIFF(SECOND, dt.StartTime, bs.backup_start_date)
  ) < 5
WHERE
  dt.EventClass = 115
  AND UPPER(CONVERT(nvarchar(max), dt.TextData)) LIKE N''BACKUP%''
  AND dt.DatabaseName=''' + @databaseName1 +''' ORDER BY dt.StartTime DESC'
    EXEC sp_executesql @sql
    FETCH NEXT FROM db_cursor INTO @databaseName1
END 
CLOSE db_cursor
DEALLOCATE db_cursor

可以看到性能極差，查詢3條資料耗時24秒，每次游標都要到消耗臨時表和進行大量的邏輯讀取，

點擊查看消耗的資源 

 SQL Server 執行時間:
   CPU 時間 = 0 毫秒，占用時間 = 0 毫秒，
表 'Worktable'，掃描計數 0，邏輯讀取 14 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'sysobjvalues'，掃描計數 14，邏輯讀取 36 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'syspalvalues'，掃描計數 0，邏輯讀取 98 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'sysguidrefs'，掃描計數 2，邏輯讀取 30 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'sysclsobjs'，掃描計數 0，邏輯讀取 0 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'syssingleobjrefs'，掃描計數 7，邏輯讀取 42 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'sysdbreg'，掃描計數 1，邏輯讀取 2 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，

(1 行受影響)

 SQL Server 執行時間:
   CPU 時間 = 31 毫秒，占用時間 = 27 毫秒，
表 'Worktable'，掃描計數 0，邏輯讀取 2 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'sysobjvalues'，掃描計數 2，邏輯讀取 6 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'syspalvalues'，掃描計數 0，邏輯讀取 14 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'sysguidrefs'，掃描計數 0，邏輯讀取 0 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'sysclsobjs'，掃描計數 0，邏輯讀取 0 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'syssingleobjrefs'，掃描計數 1，邏輯讀取 6 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'sysdbreg'，掃描計數 0，邏輯讀取 2 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，

(1 行受影響)

 SQL Server 執行時間:
   CPU 時間 = 16 毫秒，占用時間 = 23 毫秒，

 SQL Server 執行時間:
   CPU 時間 = 0 毫秒，占用時間 = 0 毫秒，

 SQL Server 執行時間:
   CPU 時間 = 0 毫秒，占用時間 = 0 毫秒，
SQL Server 分析和編譯時間: 
   CPU 時間 = 0 毫秒，占用時間 = 0 毫秒，

(1 行受影響)
表 'backupset'，掃描計數 1，邏輯讀取 3 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'Worktable'，掃描計數 0，邏輯讀取 0 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，

(1 行受影響)

 SQL Server 執行時間:
   CPU 時間 = 468 毫秒，占用時間 = 678 毫秒，

 SQL Server 執行時間:
   CPU 時間 = 468 毫秒，占用時間 = 678 毫秒，
表 'Worktable'，掃描計數 0，邏輯讀取 2 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'sysobjvalues'，掃描計數 2，邏輯讀取 6 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'syspalvalues'，掃描計數 0，邏輯讀取 14 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'sysguidrefs'，掃描計數 0，邏輯讀取 0 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'sysclsobjs'，掃描計數 0，邏輯讀取 0 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'syssingleobjrefs'，掃描計數 1，邏輯讀取 6 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'sysdbreg'，掃描計數 0，邏輯讀取 2 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，

(1 行受影響)

 SQL Server 執行時間:
   CPU 時間 = 16 毫秒，占用時間 = 23 毫秒，

 SQL Server 執行時間:
   CPU 時間 = 0 毫秒，占用時間 = 0 毫秒，

 SQL Server 執行時間:
   CPU 時間 = 0 毫秒，占用時間 = 0 毫秒，
SQL Server 分析和編譯時間: 
   CPU 時間 = 0 毫秒，占用時間 = 0 毫秒，

(0 行受影響)
表 'Worktable'，掃描計數 0，邏輯讀取 0 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，

(1 行受影響)

 SQL Server 執行時間:
   CPU 時間 = 406 毫秒，占用時間 = 732 毫秒，

 SQL Server 執行時間:
   CPU 時間 = 406 毫秒，占用時間 = 732 毫秒，
表 'Worktable'，掃描計數 0，邏輯讀取 2 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'sysobjvalues'，掃描計數 2，邏輯讀取 6 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'syspalvalues'，掃描計數 0，邏輯讀取 14 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'sysguidrefs'，掃描計數 0，邏輯讀取 0 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'sysclsobjs'，掃描計數 0，邏輯讀取 0 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'syssingleobjrefs'，掃描計數 1，邏輯讀取 6 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'sysdbreg'，掃描計數 0，邏輯讀取 2 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，

(1 行受影響)

 SQL Server 執行時間:
   CPU 時間 = 16 毫秒，占用時間 = 21 毫秒，

 SQL Server 執行時間:
   CPU 時間 = 0 毫秒，占用時間 = 0 毫秒，

 SQL Server 執行時間:
   CPU 時間 = 0 毫秒，占用時間 = 0 毫秒，
SQL Server 分析和編譯時間: 
   CPU 時間 = 0 毫秒，占用時間 = 0 毫秒，

(0 行受影響)
表 'Worktable'，掃描計數 0，邏輯讀取 0 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，

(1 行受影響)

 SQL Server 執行時間:
   CPU 時間 = 422 毫秒，占用時間 = 659 毫秒，

 SQL Server 執行時間:
   CPU 時間 = 422 毫秒，占用時間 = 660 毫秒，
表 'Worktable'，掃描計數 0，邏輯讀取 2 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'sysobjvalues'，掃描計數 2，邏輯讀取 6 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'syspalvalues'，掃描計數 0，邏輯讀取 14 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'sysguidrefs'，掃描計數 0，邏輯讀取 0 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'sysclsobjs'，掃描計數 0，邏輯讀取 0 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'syssingleobjrefs'，掃描計數 1，邏輯讀取 6 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'sysdbreg'，掃描計數 0，邏輯讀取 2 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，

(1 行受影響)

 SQL Server 執行時間:
   CPU 時間 = 15 毫秒，占用時間 = 616 毫秒，

 SQL Server 執行時間:
   CPU 時間 = 0 毫秒，占用時間 = 0 毫秒，

 SQL Server 執行時間:
   CPU 時間 = 0 毫秒，占用時間 = 0 毫秒，
SQL Server 分析和編譯時間: 
   CPU 時間 = 0 毫秒，占用時間 = 0 毫秒，

(0 行受影響)
表 'Worktable'，掃描計數 0，邏輯讀取 0 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，

(1 行受影響)

 SQL Server 執行時間:
   CPU 時間 = 375 毫秒，占用時間 = 678 毫秒，

 SQL Server 執行時間:
   CPU 時間 = 375 毫秒，占用時間 = 678 毫秒，
表 'Worktable'，掃描計數 0，邏輯讀取 2 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'sysobjvalues'，掃描計數 2，邏輯讀取 6 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'syspalvalues'，掃描計數 0，邏輯讀取 14 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'sysguidrefs'，掃描計數 0，邏輯讀取 0 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'sysclsobjs'，掃描計數 0，邏輯讀取 0 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'syssingleobjrefs'，掃描計數 1，邏輯讀取 6 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'sysdbreg'，掃描計數 0，邏輯讀取 2 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，

(1 行受影響)

 SQL Server 執行時間:
   CPU 時間 = 16 毫秒，占用時間 = 1286 毫秒，

 SQL Server 執行時間:
   CPU 時間 = 0 毫秒，占用時間 = 0 毫秒，

 SQL Server 執行時間:
   CPU 時間 = 0 毫秒，占用時間 = 0 毫秒，
SQL Server 分析和編譯時間: 
   CPU 時間 = 0 毫秒，占用時間 = 0 毫秒，

(1 行受影響)
表 'backupset'，掃描計數 1，邏輯讀取 2 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'Worktable'，掃描計數 0，邏輯讀取 0 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，

(1 行受影響)

 SQL Server 執行時間:
   CPU 時間 = 375 毫秒，占用時間 = 781 毫秒，

 SQL Server 執行時間:
   CPU 時間 = 375 毫秒，占用時間 = 781 毫秒，
表 'Worktable'，掃描計數 0，邏輯讀取 2 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'sysobjvalues'，掃描計數 2，邏輯讀取 6 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'syspalvalues'，掃描計數 0，邏輯讀取 14 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'sysguidrefs'，掃描計數 0，邏輯讀取 0 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'sysclsobjs'，掃描計數 0，邏輯讀取 0 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'syssingleobjrefs'，掃描計數 1，邏輯讀取 6 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'sysdbreg'，掃描計數 0，邏輯讀取 2 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，

(1 行受影響)

 SQL Server 執行時間:
   CPU 時間 = 31 毫秒，占用時間 = 1608 毫秒，

 SQL Server 執行時間:
   CPU 時間 = 0 毫秒，占用時間 = 0 毫秒，

 SQL Server 執行時間:
   CPU 時間 = 0 毫秒，占用時間 = 0 毫秒，
SQL Server 分析和編譯時間: 
   CPU 時間 = 13 毫秒，占用時間 = 13 毫秒，

(1 行受影響)
表 'backupset'，掃描計數 1，邏輯讀取 3 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'Worktable'，掃描計數 0，邏輯讀取 0 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，

(1 行受影響)

 SQL Server 執行時間:
   CPU 時間 = 390 毫秒，占用時間 = 737 毫秒，

 SQL Server 執行時間:
   CPU 時間 = 406 毫秒，占用時間 = 751 毫秒，
表 'Worktable'，掃描計數 0，邏輯讀取 2 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'sysobjvalues'，掃描計數 2，邏輯讀取 6 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'syspalvalues'，掃描計數 0，邏輯讀取 14 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'sysguidrefs'，掃描計數 0，邏輯讀取 0 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'sysclsobjs'，掃描計數 0，邏輯讀取 0 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'syssingleobjrefs'，掃描計數 1，邏輯讀取 6 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'sysdbreg'，掃描計數 0，邏輯讀取 2 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，

(1 行受影響)

 SQL Server 執行時間:
   CPU 時間 = 16 毫秒，占用時間 = 20 毫秒，

 SQL Server 執行時間:
   CPU 時間 = 0 毫秒，占用時間 = 0 毫秒，

 SQL Server 執行時間:
   CPU 時間 = 0 毫秒，占用時間 = 0 毫秒，
SQL Server 分析和編譯時間: 
   CPU 時間 = 12 毫秒，占用時間 = 12 毫秒，

(0 行受影響)
表 'Worktable'，掃描計數 0，邏輯讀取 0 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，

(1 行受影響)

 SQL Server 執行時間:
   CPU 時間 = 468 毫秒，占用時間 = 2492 毫秒，

 SQL Server 執行時間:
   CPU 時間 = 484 毫秒，占用時間 = 2505 毫秒，
表 'Worktable'，掃描計數 0，邏輯讀取 2 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'Worktable'，掃描計數 0，邏輯讀取 0 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'Worktable'，掃描計數 0，邏輯讀取 0 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，

(1 行受影響)

 SQL Server 執行時間:
   CPU 時間 = 16 毫秒，占用時間 = 23 毫秒，

 SQL Server 執行時間:
   CPU 時間 = 0 毫秒，占用時間 = 0 毫秒，

 SQL Server 執行時間:
   CPU 時間 = 0 毫秒，占用時間 = 0 毫秒，

 SQL Server 執行時間:
   CPU 時間 = 0 毫秒，占用時間 = 0 毫秒，
SQL Server 分析和編譯時間: 
   CPU 時間 = 0 毫秒，占用時間 = 0 毫秒，

 SQL Server 執行時間:
   CPU 時間 = 0 毫秒，占用時間 = 0 毫秒，

image

  1. 第2種，使用MAX函式和group by優化
SELECT
    [Status] = MAX(CASE
      WHEN bs.backup_start_date IS NULL THEN dt.DatabaseName+'資料庫備份失敗'
      ELSE dt.DatabaseName+'資料庫備份成功'
    END)
  FROM
    sys.fn_trace_gettable(
      (
        SELECT
          REVERSE(
            SUBSTRING(
              REVERSE([path]),
              CHARINDEX(CHAR(92), REVERSE([path])),
              260
            )
          ) + N'log.trc'
        FROM
          sys.traces
        WHERE
          is_default = 1
      ),
      default
    ) AS dt
    LEFT OUTER JOIN msdb.dbo.backupset AS bs ON dt.DatabaseName = bs.database_name
      AND ABS(DATEDIFF(SECOND, dt.StartTime, bs.backup_start_date)) < 5
  WHERE
    dt.EventClass = 115
    AND UPPER(CONVERT(nvarchar(max), dt.TextData)) LIKE 'BACKUP%'
  GROUP BY
    dt.DatabaseName

這次執行只要1秒鐘，占用的資源也極低，

SQL Server 分析和編譯時間: 
   CPU 時間 = 15 毫秒，占用時間 = 20 毫秒，

(3 行受影響)
表 'Worktable'，掃描計數 0，邏輯讀取 0 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，
表 'backupset'，掃描計數 1，邏輯讀取 48 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次，

 SQL Server 執行時間:
   CPU 時間 = 469 毫秒，占用時間 = 935 毫秒，
SQL Server 分析和編譯時間: 
   CPU 時間 = 0 毫秒，占用時間 = 0 毫秒，

 SQL Server 執行時間:
   CPU 時間 = 0 毫秒，占用時間 = 0 毫秒，

image

截止到此，基本大功告成了，接下來要實作的就是監控系統怎么取得指標和觸發告警，具體可以根據不同的監控平臺進行配置，
實際上還可以通過xp_readerrorlog來讀取errorlog更加快速得篩選出備份失敗的記錄，但本次沒有再測驗，有興趣的朋友可以自行參考測驗，
image

5 使用xp_readerrorlog監控準確性更高

2023年5月10日增加：??在實際生產環境中，我們發現使用了NBU類的備份系統對資料庫進行備份時，NBU備份的啟動時間在log trace的時間要晚了10幾秒，這就導致上面的腳本判斷失敗了，最后確定通過xp_readerrorlog來讀取errorlog，確保監控資料的準確性，參考腳本：

DECLARE @Logs TABLE
(
    LogDate DATETIME,
    ProcessInfo NVARCHAR(24),
    Text VARCHAR(1000)
)


INSERT INTO @Logs EXEC sp_readerrorlog 0, 1, N'Backup failed'

DECLARE @keyword VARCHAR(50);
DECLARE @num_keywords INT;
DECLARE @i INT;

SET @num_keywords = (SELECT COUNT(*) FROM sysdatabases);
SET @i = 1;

WHILE (@i <= @num_keywords)
BEGIN
  SET @keyword = (SELECT name FROM sysdatabases WHERE dbid = @i);
    SELECT TOP 1 LogDate,SUBSTRING([Text], PATINDEX('%' + @keyword + '%', [Text]), LEN(@keyword))+'備份失敗' AS Result
  FROM @Logs
  WHERE PATINDEX('%' + @keyword + '%', [Text]) > 0
  ORDER BY LogDate DESC;
  SET @i = @i + 1;
END;

轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/552168.html

標籤：其他

上一篇：基于華為云圖引擎GES，使用Cypher子查詢進行圖探索

下一篇：返回列表

標籤雲
其他(158826) Python(38125) JavaScript(25413) Java(18025) C(15225) 區塊鏈(8264) C＃(7972) AI(7469) 爪哇(7425) MySQL(7177) html(6777) 基礎類(6313) sql(6102) 熊猫(6058) PHP(5871) 数组(5741) R(5409) Linux(5338) 反应(5209) 腳本語言(PerlPython)(5129) 非技術區(4971) Android(4570) 数据框(4311) css(4259) 节点.js(4032) C語言(3288) json(3245) 列表(3129) 扑(3119) C++語言(3117) 安卓(2998) 打字稿(2995) VBA(2789) Java相關(2746) 疑難問題(2699) 细绳(2522) 單片機工控(2479) iOS(2432) ASP.NET(2402) MongoDB(2323) 麻木的(2285) 正则表达式(2254) 字典(2211) 循环(2198) 迅速(2185) 擅长(2169) 镖(2155) .NET技术(1972) 功能(1967) Web開發(1951) HtmlCss(1935) python-3.x(1918) 弹簧靴(1913) C++(1913) xml(1889) PostgreSQL(1875) .NETCore(1860) 谷歌表格(1846) Unity3D(1843) for循环(1842)

熱門瀏覽
  • GPU虛擬機創建時間深度優化

    **?桔妹導讀：**GPU虛擬機實體創建速度慢是公有云面臨的普遍問題，由于通常情況下創建虛擬機屬于低頻操作而未引起業界的重視，實際生產中還是存在對GPU實體創建時間有苛刻要求的業務場景。本文將介紹滴滴云在解決該問題時的思路、方法、并展示最終的優化成果。 從公有云服務商那里購買過虛擬主機的資深用戶，一 ......

    uj5u.com 2020-09-10 06:09:13 more
  • 可編程網卡芯片在滴滴云網路的應用實踐

    **?桔妹導讀：**隨著云規模不斷擴大以及業務層面對延遲、帶寬的要求越來越高，采用DPDK 加速網路報文處理的方式在橫向縱向擴展都出現了局限性。可編程芯片成為業界熱點。本文主要講述了可編程網卡芯片在滴滴云網路中的應用實踐，遇到的問題、帶來的收益以及開源社區貢獻。 #1. 資料中心面臨的問題 隨著滴滴 ......

    uj5u.com 2020-09-10 06:10:21 more
  • 滴滴資料通道服務演進之路

    **?桔妹導讀：**滴滴資料通道引擎承載著全公司的資料同步，為下游實時和離線場景提供了必不可少的源資料。隨著任務量的不斷增加，資料通道的整體架構也隨之發生改變。本文介紹了滴滴資料通道的發展歷程，遇到的問題以及今后的規劃。 #1. 背景 資料，對于任何一家互聯網公司來說都是非常重要的資產，公司的大資料 ......

    uj5u.com 2020-09-10 06:11:05 more
  • 滴滴AI Labs斬獲國際機器翻譯大賽中譯英方向世界第三

    **桔妹導讀：**深耕人工智能領域，致力于探索AI讓出行更美好的滴滴AI Labs再次斬獲國際大獎，這次獲獎的專案是什么呢？一起來看看詳細報道吧！ 近日，由國際計算語言學協會ACL（The Association for Computational Linguistics）舉辦的世界最具影響力的機器 ......

    uj5u.com 2020-09-10 06:11:29 more
  • MPP (Massively Parallel Processing)大規模并行處理

    1、什么是mpp？ MPP (Massively Parallel Processing)，即大規模并行處理，在資料庫非共享集群中，每個節點都有獨立的磁盤存盤系統和記憶體系統，業務資料根據資料庫模型和應用特點劃分到各個節點上，每臺資料節點通過專用網路或者商業通用網路互相連接，彼此協同計算，作為整體提供 ......

    uj5u.com 2020-09-10 06:11:41 more
  • 滴滴資料倉庫指標體系建設實踐

    **桔妹導讀：**指標體系是什么？如何使用OSM模型和AARRR模型搭建指標體系？如何統一流程、規范化、工具化管理指標體系？本文會對建設的方法論結合滴滴資料指標體系建設實踐進行解答分析。 #1. 什么是指標體系 ##1.1 指標體系定義 指標體系是將零散單點的具有相互聯系的指標，系統化的組織起來，通 ......

    uj5u.com 2020-09-10 06:12:52 more
  • 單表千萬行資料庫 LIKE 搜索優化手記

    我們經常在資料庫中使用 LIKE 運算子來完成對資料的模糊搜索，LIKE 運算子用于在 WHERE 子句中搜索列中的指定模式。 如果需要查找客戶表中所有姓氏是“張”的資料，可以使用下面的 SQL 陳述句： SELECT * FROM Customer WHERE Name LIKE '張%' 如果需要 ......

    uj5u.com 2020-09-10 06:13:25 more
  • 滴滴Ceph分布式存盤系統優化之鎖優化

    **桔妹導讀：**Ceph是國際知名的開源分布式存盤系統，在工業界和學術界都有著重要的影響。Ceph的架構和演算法設計發表在國際系統領域頂級會議OSDI、SOSP、SC等上。Ceph社區得到Red Hat、SUSE、Intel等大公司的大力支持。Ceph是國際云計算領域應用最廣泛的開源分布式存盤系統， ......

    uj5u.com 2020-09-10 06:14:51 more
  • es~通過ElasticsearchTemplate進行聚合~嵌套聚合

    之前寫過《es~通過ElasticsearchTemplate進行聚合操作》的文章，這一次主要寫一個嵌套的聚合，例如先對sex集合，再對desc聚合，最后再對age求和，共三層嵌套。 Aggregations的部分特性類似于SQL語言中的group by，avg，sum等函式,Aggregation ......

    uj5u.com 2020-09-10 06:14:59 more
  • 爬蟲日志監控 -- Elastc Stack（ELK）部署

    傻瓜式部署，只需替換IP與用戶 導讀： 現ELK四大組件分別為：Elasticsearch（核心）、logstash（處理）、filebeat（采集）、kibana（可視化） 下載均在https://www.elastic.co/cn/downloads/下tar包，各組件版本最好一致，配合fdm會 ......

    uj5u.com 2020-09-10 06:15:05 more
最新发布
  • SQL Server資料庫判斷最近一次的備份執行結果

    1 麻煩的地方 在SQL Server的官方檔案里面可以看到備份和還原的表，但是這些表里面只能找到備份成功的相關資訊，無法找到備份失敗的記錄，比如msdb.dbo.backupset。對于一些監控系統未監控作業的情況下，想要監控資料庫備份任務執行失敗而觸發告警規則，有些麻煩。 但是SQL serve ......

    uj5u.com 2023-05-11 08:36:30 more
  • 基于華為云圖引擎GES，使用Cypher子查詢進行圖探索

    摘要：本文以華為云圖引擎 GES 為例，來介紹如何使用圖查詢語言 Cypher 表達一些需要做資料區域遍歷的場景。 本文分享自華為云社區《使用 Cypher 子查詢進行圖探索 -- 以華為云圖引擎 GES 為例》，作者：蜉蝣與海。 在圖資料庫 / 圖計算領域，很多查詢可以使用圖查詢語言 Cypher ......

    uj5u.com 2023-05-11 08:29:48 more
  • SQL Server資料庫判斷最近一次的備份執行結果

    1 麻煩的地方 在SQL Server的官方檔案里面可以看到備份和還原的表，但是這些表里面只能找到備份成功的相關資訊，無法找到備份失敗的記錄，比如msdb.dbo.backupset。對于一些監控系統未監控作業的情況下，想要監控資料庫備份任務執行失敗而觸發告警規則，有些麻煩。 但是SQL serve ......

    uj5u.com 2023-05-11 08:29:15 more
  • 從快取的本質說起，說服技術大佬用Redis

    摘要：在技術領域中，沒有銀彈。我們需要不斷探索和研究新的技術，結合具體問題和需求，選擇最適合的解決方案。 本文分享自華為云社區《知乎問題：如何說服技術老大用 Redis ？》，作者：勇哥java實戰分享。 最近在某問答平臺看到一個技術討論：如何說服技術老大用Redis? “他總覺得用Redis每次都 ......

    uj5u.com 2023-05-11 08:28:47 more
  • V$INDEX_USAGE_INFO中找不到監控索引資料的尷尬經歷

    在一個Oracle 12.1實體中，想監控一個表的索引使用情況，在system用戶下執行了下面腳本以及輸出的監控索引腳本后，發現V$OBJECT_USAGE下一直沒有對應的記錄（在system用戶下查詢） SELECT 'ALTER INDEX '||OWNER||'.'||INDEX_NAME|| ......

    uj5u.com 2023-05-11 08:28:24 more
  • Oracle之table()函式的使用，提高查詢效率

    (Oracle之table()函式) 一、序言 前段時間一直在弄報表，快被這些報表整吐了，然后接觸到了Oracle的table()函式。所以今天把table()函式的具體用法整理下，防止下次遇到忘記了。。 利用table()函式，可接收輸入引數，然后將pl/sql 回傳的結果集代替table。由于表 ......

    uj5u.com 2023-05-11 08:28:19 more
  • mysql資料記錄

    mysql資料記錄 準備作業 創建庫、表 #創建資料庫 create database mysql02; #使用資料庫 use mysql02; #創建表 create table student(id int ,name varchar(10),age int); 查看student表結構 資料增 ......

    uj5u.com 2023-05-11 08:27:58 more
  • 如何進行MySQL原始碼除錯（一條select陳述句的執行流程）

    一、背景 MySQL是當今世上最受歡迎的使用最廣泛的開源資料庫，它的繁榮離不開它的開源特性。放在過去商業資料庫的時代，大家都沒有機會接觸到資料庫的源代碼，但在如今開源資料庫的時代，越來越多的人開始研究資料庫的原始碼，并給社區貢獻代碼，MySQL官方每次發布新版本都要感謝一些在社區上貢獻代碼的程式員。現 ......

    uj5u.com 2023-05-11 08:27:50 more
  • 如何從800萬資料中快速撈出自己想要的資料？

    (如何從800萬資料中快速撈出自己想要的資料) 一、需求調研 正如題目所說，我們使用的是Oracle資料庫，資料量在800萬左右。我們要完成的事情就是在著800萬資料中，通過某些欄位進行模糊查詢，得到我們所需要的結果集。 這是表里的資料，一共7328976 條資料，接近800萬 select cou ......

    uj5u.com 2023-05-10 09:55:11 more
  • 實驗六 存盤程序

    #實驗六 存盤程序 第1關：增加供應商相關列sqty use demo; #代碼開始 #在S表中增加一列供應零件總數量（sqty），默認值為0。 altertable s add sqty intdefault0; #代碼結束 desc s; 第2關：定義、呼叫簡單存盤程序 use demo; #代 ......

    uj5u.com 2023-05-10 09:47:32 more

Copyright © 2010-2020 有解無憂