Zanim błąd i szef zapukają do drzwi

wpis w: implementacja, migawka, t-sql | 2

Czy zdażyło się wam odtwarzać po raz kolejny bazę danych po logicznym uszkodzeniu plików?

Wlaściwie kiedy ostatnio sprawdzano ją dostępnymi narzędziami?
Kiedy ostanio dokonano pełnej, różnicowej kopii bezpieczeństwa, jak często odkładane są logi transakcyjne?
Czy baza ma poprawny model recovery ?
Jeśli na chociaż jedno pytanie pojawiły się w głowie wątpliwości, to dobrze, że przed awarią…

 

Pomocny skrypt

 if object_id('tempdb..#DBInfo') is not null
		DROP TABLE #DBInfo
 if object_id('tempdb..#DBCC') is not null
		DROP TABLE #DBCC
CREATE TABLE #DBInfo (
       Id bigint IDENTITY(1,1),
       ParentObject VARCHAR(255),
       [Object] VARCHAR(255),
       Field VARCHAR(255),
       [Value] VARCHAR(255)
)
CREATE TABLE #DBCC(
DatabaseName VARCHAR(255),
LastDBCCCHeckDB_RunDate VARCHAR(255)
)
EXECUTE SP_MSFOREACHDB'INSERT INTO #DBInfo Execute (''DBCC DBINFO ( ''''?'''') WITH TABLERESULTS'');
INSERT INTO #DBCC (DatabaseName) SELECT [Value] FROM #DBInfo WHERE Field IN (''dbi_dbname'');
UPDATE #DBCC SET LastDBCCCHeckDB_RunDate=(SELECT TOP 1 [Value] FROM #DBInfo WHERE Field IN (''dbi_dbccLastKnownGood'')) where LastDBCCCHeckDB_RunDate is NULL;
TRUNCATE TABLE #DBInfo';
  
SELECT 
      database_name = DB_NAME(d.database_id)
    , log_size_gb = CAST(SUM(CASE WHEN d.type_desc = 'LOG' THEN d.size END) * 8. / 1024/1024 AS DECIMAL(10,4))
    , row_size_gb = CAST(SUM(CASE WHEN d.type_desc = 'ROWS' THEN d.size END) * 8. / 1024/1024 AS DECIMAL(10,4))
    , total_size_gb = CAST(SUM(d.size * 8. / 1024/1024) AS DECIMAL(10,4)),
       db.recovery_model_desc,
       cc.LastDBCCCHeckDB_RunDate
FROM sys.master_files  d WITH(NOWAIT)
join  #DBCC cc
on (cc.DatabaseName=DB_NAME(d.database_id) )
join sys.databases  db
on (db.database_id=d.database_id)

GROUP BY d.database_id,cc.LastDBCCCHeckDB_RunDate,db.recovery_model_desc
order by cc.LastDBCCCHeckDB_RunDate,4 desc


;WITH LastBackUp AS
(
SELECT  bs.database_name,
        bs.backup_size,
        bs.backup_start_date,
        bmf.physical_device_name,
        Position = ROW_NUMBER() OVER( PARTITION BY bs.database_name ORDER BY bs.backup_start_date DESC )
FROM  msdb.dbo.backupmediafamily bmf
JOIN msdb.dbo.backupmediaset bms ON bmf.media_set_id = bms.media_set_id
JOIN msdb.dbo.backupset bs ON bms.media_set_id = bs.media_set_id
WHERE   bs.[type] = 'D'
AND bs.is_copy_only = 0
)
SELECT 
       database_name AS [Database],
       CAST(backup_size / 1024/1024/1024 AS DECIMAL(10, 2) ) AS [BackupSizeMB],
        backup_start_date AS [Last Full DB Backup Date],
        physical_device_name AS [Backup File Location]
FROM LastBackUp
WHERE Position = 1
ORDER BY [Database];


Hipotetyczny rezultat powyższego zapytania

database_nametotal_size_gbrecovery_model_descLastDBCCCHeckDB_RunDate
XYZ153.8079SIMPLE1900-01-01 00:00:00.000
tempdb58.6021SIMPLE1900-01-01 00:00:00.000
HURT49.2092SIMPLE1900-01-01 00:00:00.000
ABC46.6123SIMPLE1900-01-01 00:00:00.000
ZZA0.4893FULL1900-01-01 00:00:00.000
model0.1470SIMPLE1900-01-01 00:00:00.000
master0.0148SIMPLE1900-01-01 00:00:00.000
msdb5.8594SIMPLE2015-10-06 13:34:30.730

Na co zwrócić uwagę ?

Bazy systemowe (master, model,msdb,tempdb) mają ustawiony recovery model równy SIMPLE. Żadna z nich, poza msdb nie była nigdy sprawdzona narzędziem DBCC CheckDB ? To dobrze ?

Jedyna baza w trybie FULL teź nigdy nie została sprawdzona.

Do odważnych świat należy,ale nie do nieroztropnych.

https://www.mssqltips.com/sqlservertip/4381/sql-server-dbcc-checkdb-overview/

2 Responses

  1. mmoskit

    Warto pamiętać, że kiedy baza jest w FULL recovery mode a nie było zrobionego pełnego backupu bazy to tak naprawdę zachowuje się jak w SIMPLE

    • djkormo

      Nie wiem, czy gratulować takiemu administratorowi ?

      Dobry administrator w starym stylu, to taki, którego pracy praktycznie nie widać, a systemy działają tygodniami, miesiącami i latami…..

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.